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'Abstract 

This  is  ths  tins!  rsport  on  RAOC  Protect  P30802-80-C0022. 

Work  on  Ade  sdvsnced  error  detection  has  encompassed  three  areas  of  research  and  development. 

1.  Techniquea  ol  detecting  common  runtime  errors  in  seguential  Ada  at  compile-time  using 
veritlcatlon  techniquee. 

2.  High  level  annotation  iengusgea. 

3.  Runtime  detection  of  desdness  errors  in  Ada  tasking. 

Interim  Report  1  dealt  with  work  on  runtime  detection  of  common  errors. 

Interim  Report  2  contains  the  project  work  on  a  preliminary  design  study  for  a  high  level  annotation 
language  for  Ada. 

This  final  report  deals  with  our  work  on  runtime  detection  of  errors  in  Ada  Tasking  programs. 

This  report  contains  a  preface  summarizing  briefly  the  work  in  the  first  two  interim  reports.  The  report 
then  deals  with  the  results  and  progress  of  our  work  on  tasking  error  detection.  This  work  has 
resulted  in  a  working  prototype  Implementation  of  a  system  tor  detecting  and  diagnosing  tasking 
errors.  Source  code  of  this  implementation  has  been  supplied  to  RADC. 

This  system  is  the  most  promising  approach  to  detection  of  deadness  errors  and  debugging  of  Ada 
tasking  programs  developed  so  far.  Its  application  to  evasive  action  programming  as  a  standard 
technique  tor  large  Ada  distributed  systems  merits  further  study.  It  is  our  opinion  that  if  this  research 
and  development  is  pursued  along  the  direction  taken  in  this  project,  runtime  monitoring  systems  of 
production  quality  standards  for  analysis  and  debugging  of  Ada  tasking  programs  can  be  available  for 
incorporation  into  Ada  Program  Support  Environments  in  the  next  2  -  4  years,  depending  on  the  level 
of  effort.  Such  production  quality  tools  would  essentially  be  developments  of  the  prototype 
experimental  system  developed  under  this  contract  and  described  in  this  report. 
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Work  on  Ada  advanced  error  detection  hoe  encompassed  three  sreas  of  research  and  development 

1.  Techniquee  of  detecting  common  runtime  errors  in  sequential  Ada  at  eompile>time  using 
verMeation  techniquea. 

Z  High  level  annotation  languages. 

Z  Runtime  detection  of  deadnass  errors  in  Ada  tasking. 

Area  1  was  our  initial  research  focus  during  the  first  year.  This  research  was  based  on  previous  work 
on  the  compiie-time  detection  of  common  errors  in  Pascal  [German  8i ,  Pascal  Verifier  79].  This 
previous  work  was  judged  to  be  a  good  starting  point  for  the  effort  since  the  previous  work  applied  to 
ail  Algol'like  languages,  including  the  sequential  subset  of  Ada,  and  therefore  promised  quick  results 
in  terms  of  application  to  Ada.  Common  errors  whose  presence  can  be  detected  at  compile- time 
include  accessing  of  unitialized  variables,  array  indexing  errors,  sub-range  errors,  etc.  The 
techniques  developed  require  use  cf  advanced  mathematical  veriRcation  methods  such  as  those 
implemented  in  [Pascal  Verifier  79].  The  advantages  resulting  are  quantified  in  terms  of  runtime 
efficiency  of  tlie  compiled  Ada  program  gained  by  suppression  of  unnecessary  runtime  checking. 
The  results  and  details  of  this  part  of  die  research  are  treated  in  detail  in  our  Interim  Report  No.  i 
dated  1  February  1981. 

The  ability  to  detect  errors  in  the  semantics  of  an  Ada  program  itself,  as  opposed  to  a  simpie  common 
error  due  to  transgreesing  the  general  semantics  of  the  Ada  language,  requires  development  of  a 
specification  language  for  Ada.  Such  a  language  must  provide  the  programmer  with  sufficiently 
powerful  fticilities  to  express  speeificetions  for  Ada  programs  within  a  r/ntactic  and  semantic 
framework  that  matches  Ada  itself  where  possible.  Given  both  formal  specification  and  Ada  text,  it  is 
then  possible  to  construct  automated  interactive  debugging  tools  such  as  verifiers,  teat  ease 
generators  and  symbolic  executors,  for  detecting  incbneistsncies  between  the  specification  and  code 
of  an  Ada  program.  The  major  problem  lay  first  in  the  lack  of  an  adequate  specification  language  for 
Ada  programs.  Previous  specification  languagee.  e.g.  for  Pascal,  were  judged  inadequate  for 
application  to  Ada. 

Part  of  our  second  year  effort  was  therefore  devoted  to  a  design  study  for  a  high  level  specification 
language  called  Anna  for  expressing  formal  specifications  of  Ada  programs  in  a  machine  processable 
form.  In  Anna  formal  comments  are  written  with  the  same  precision  as  programs,  and  included  as  an 
extension  of  Ada  programs.  Formal  comments  are  either  virtual  Ada  text  or  annotations.  Since 
annotations  have  a  well-defined  syntactical  structure  in  ANNotated  Ada.  they  can  be  processed  by 
tools  such  as  verifiers,  optimizers,  documentation  systems  and  support  tools  for  program 
development 

In  this  preliminary  design,  we  had  four  principol  considerations. 
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1.  Constructing  annotations  shouid  bs  easy  for  the  Ada  programmer,  and  shouid  depend  as 
much  as  possibie  on  notation  and  concepts  of  Ada. 

Z  Anna  shouid  possess  ianguage  features  that  are  wideiy  used  in  the  specification  and 
documentation  of  programs. 

3.  Anna  shouid  provide  a  formai  framework  within  which  different  theories  of  specihying 
programs  may  be  appUed  to  Ada. 

4.  Annotatione  shouid  be  equaily  weii  suited  for  different  possibie  appiications,  not  only  for 
formal  verification  by  also  for  specification  of  program  parts  during  program  design  and 
development 

The  Anna  design  requirements  place  heavy  emphasis  on  developing  the  ways  in  which  Anna  can  be' 
used  for  specification  and  how  it  may  be  extended  in  the  future.  As  a  consequence  of  the  choice  of  a 
first  order  annotation  language,  different  theories  and  techniques  of  specifying  programs  may  be 
applied  using  Anna.  For  example,  previous  work  on  assertional  specification  of  Pascal  programs 
[Hoare  69.  Hoare.Wirth  73,  Luckham.Karp  79,  Pascal  Verifier  79]  may  be  formulated  in  Anna  since 
any  programming  concept  may  be  defined  by  the  first  order  axiomatic  method  (axioms  are  simply 
stated  as  annotations)  and  used  in  annotations.  It  is  also  clear  that  the  algebraic  method  of  specifying 
abstract  data  types  may  be  applied  to  packages  in  Anna. 

The  preliminary  Anna  design  (Interim  Report  No.  2)  is  incomplete,  and  may  require  further  extensions. 
First,  some  possibly  useful  specification  concepts  are  not  provided.  Consider  for  instance  modal 
operators.  These  have  to  be  defined  axiomaticaily  at  the  moment,  but  it  may  be  useful  to  include  them 
among  the  basic  predefined  operators  in  later  versions.  Secondly,  Anna  does  not  include  tasking.  An 
extension  to  include  (ask  annotations  may  require  the  introduction  of  new  predefined  attributes,  for 
example  task  type  collections,  and  the  semantics  of  task  annotations  wilt  have  to  be  defined. 

The  Anna  specification  language  is  still  under  development,  together  with  the  methodology  for 
compiling  formai  Anna  specifications  into  Ada  runtime  checking  coda.  Interim  Report  No.  2  dated  1 
February  1982  gives  a  preliminary  design  for  Anna  developed  urKfer  this  effort,  which  formed  the 
basis  for  feasibility  studies,  and  experimentation  preliminary  to  undertaking  a  more  complete  design 
effort 

As  pointed  out  in  Interim  Reoort  No.  2,  the  state  of  basic  research  concerning  errors  specific  to 
parallelism  in  multiprocesaing  programs  has  not  progressed  to  a  stage  where  it  is  practicable  to 
design  a  formal  specification  language  for  Ada  tasking.  The  major  portion  of  our  effort  related  to 
detection  of  Ada  tasking  errors  has  therefore  concentrated  on  runtime  monitoring  techniques.  Our 
research  and  development  efforts  in  this  area  have  been  highly  successful  and  promising. 

Errors  caused  by  failure  in  the  parallelism  of  a  computational  system  are  called  deedness  errors. 
These  errors  are  the  result  of  a  breakdown  in  the  communication  between  parallel  threads  of  control 
in  a  system.  As  a  consequence,  certain  threads  of  control  (or  sometimes  all  threads  in  an  entire 
system)  cannot  proceed  with  their  computations  and  hence  become  "dead".  Csadness  errors  in 
general  occur  unpredictably.  Whether  or  not  a  possible  deadness  error  in  a  system  will  occur  during 
system  operation  may  depend  on  a  muititude  of  external  factors,  e.g.  compilation  techniques,  runtime 
scheduling,  I/O  processing  times  and  external  interrupts.  They  are  often  extremely  difficult  to 
reproduce  and  hence  to  locate  by  current  testing  methods. 
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During  th«  second  and  third  years  of  this  research,  our  major  effort  has  concentrated  on  development 
of  technology  and  tools  for  detection  of  deadness  errors  in  Ada  tasking.  Our  focus  was  to  provide 
tools  for  instrumenting  tasking  programs  so  that  deadness  errors  could  be  detected  and  diagnostics 
supplied  to  the  programmer  for  debugging  purposes.  This  effort  has  resulted  in  a  significant 
breakthrough  in  the  area  of  advanced  error  detectors  for  parallel  processing. 

(Ih  A  transformational  method  for  instrumenting  Ada  source  text  in  order  to  monitor  for  deadness 
errors  in  tasking  was  defined.  This  method  applied  to  errors  due  to  Ada  rendezvous  failure.  A 
preliminary  paper  was  published  in  the  1982  Ada  Symposium,  [German,Hslmbold,Luckham  82]. 

n>.  An  abstract  method  of  representing  Ada  task  rendezvous  states  and  detecting  certain  kinds  of 
deadness  errors  was  also  developed  and  published  in  the  1982  Ada  Symposium, 
IGerman,Heimbold,Luckham  82]. 

(Uf).  The  traneformational  instrumentation  method  was  extended  significantly  to  enable  detection  of 
deadness  errors  due  to  termination  tailures  in  Ada  tasking.  This  entailed  monitoring  of  task 
dependency  information  (see  this  final  report). 

(iv).  The  transformational  instrumentation  method  was  extended  significantly  to  enable  monitoring  of 
information  for  diagnostic  description  of  deadness  errors  sufficient  to  enable  the  programmer  to 
locate  the  source  of  an  error  in  the  Ada  text  (see  this  final  report). 

M.  The  more  developed  transformational  instrumentation  was  implemented  as  a  Snobol 
preprocessor  for  Ada  source  text  (see  this  final  report.  Chapter  4). 

(vil  A  method  of  monitoring  tasking  information  supplied  by  instrumented  Ada  programs  (i.e., 
programs  to  which  the  Snobol  preprocessor  has  been  applied)  and  detecting  errors  and 
supplying  diagnostics  was  developed  and  implemented  in  Ada.  This  Ada  program,  consistng  of 
a  package  and  a  task  is  referred  to  as  the  runtime  monitor  (described  in  this  final  re;,  'rt, 
Chapter  3). 

(vil).  Testing  of  our  runtime  monitoring  system  (preprocessor  snd  monitor)  on  Ada  programs  led  to  an 
experimental  development  of  it  for  application  to  eves/ve  action  programming  (see  this  report). 

(vfir//.The  monitoring  system  was  demonstrated  at  Stanford  University  to  RAOC  representatives  in  i3th 
and  14th  July  1982. 

Ox).  Snobol  source  text  of  the  preprocessor  and  Ada  source  text  of  the  runtime  monitor  were 
supplied  via  APPA  net  to  the  RAOC  project  monitor  on  December  1982. 

This  final  report  contains  a  theory  of  daadness  errors  upon  which  our  runtime  detection  methods  are 
based,  an  overview  of  our  prototype  runtime  monitor  and  preprocessor  designs,  and  examples  of 
experiments.  This  system  is  the  most  promising  approach  to  detection  of  deadness  errors  and 
debugging  of  Ada  tasking  programs  developed  so  far.  Its  application  to  evasive  action  programming 
as  a  standard  technique  for  large  Ada  distributed  systems  merits  further  study.  It  is  our  opinion  that  if 
this  research  and  development  is  pursued  along  the  direction  taken  in  this  project,  runtime 
monitoring  systems  of  production  quality  standards  for  analysis  and  debugging  of  Ada  tasking 
programs  can  be  available  for  incorporation  into  Ada  Program  Support  Environments  in  the  next  2  •  4 
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years,  dependinr]  on  the  level  of  effort  Such  production  qualih/  too.ls  would  essentially  be 
developments  of  the  protoh/pe  experimental  system  developed  under  this  contract  and  described  in 
this  report. 


Professor  David  C.  Luckham 
Principle  Investigator 
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1.  INTRODUCTION 

Errors  caused  by  failure  in  the  parallelism  of  a  computational  system  are  called  deadness  errors. 
These  errors  are  the  result  of  a  breakdown  in  the  communication  between  parallel  threads  of  control 
in  a  system.  As  a  consequence,  certain  threads  of  control  (or  sometimes  ail  threads  in  an  entire 
system)  cannot  proceed  with  their  computations  and  hence  become  "dead".  Oeadness  errors  in 
general  occur  unpredictably.  Whether  or  not  a  possible  deadness  error  in  a  system  will  occur  during 
system  operation  may  depend  on  a  multitude  of  external  factors,  e.g.  compilation  techniques,  runtime 
scheduling,  I/O  processing  times  and  external  interrupts.  They  are  often  extremely  difficult  to 
reproduce  and  hence  to  locate  by  current  testing  methods. 

Oeadness  errors  have  been  described  in  the  past  by  concepts  such  as  deadlock,  blocking,  and 
starvation.  These  early  concepts  provided  meaningful  classification  of  certain  kinds  of  errors  that 
could  occur  in  1960*S  vintage  parallel  (or  pseudo  parallel)  systems  such  as  simple  operating  systems. 
However  they  are  too  vague  for  describing  the  kinds  of  deadness  error  that  can  occur  in  a  parallel 
system  implemented  using  the  multi-tasking  facilities  of  Ada.  For  example,  if  a  system  uses  dynamic 
activation  of  tasks,  the  number  of  active  tasks  at  any  time  will  be  a  function  of  what  the  system  is 
doing,  and  may  not  be  determinable  m  advance.  Names  can  only  be  assigned  dynamically  to  new 
tasks.  In  such  cases,  a  runtime  diagnostic  such  as  "tasks  25.  37,  and  121  have  oeadlocked"  will  not 
be  very  helpful  because  the  dynamically  assigned  names.  25,  37,  121  have  no  meaning  related  to  ttie 
system  source  text.  Additional  descriptive  information  such  as  the  Ada  types  of  tasks  must  be 
provided.  Before  we  can  expect  to  develop  an  ability  to  deal  v/ith  deadness  In  future  parallel  systems, 
we  must  first  provide  adequate  methods  of  classification  and  description. 

In  order  to  deal  with  deadness  in  Ada  or  other  languages  of.similar  complexity,  it  is  useful  to  divide  the 
problem  into  three  sub-problems:  U)  deiecUon,  (H)  description,  and  (Hi)  avoidance.  Detection  involves 
recognizing  a  dead  state,  and  usually  requires  less  information  than  description.  Description  involves 
providing  sufficient  information  to  locate  the  source  of  an  error  in  Ada  text.  Avoidance  involves  both 
style  guidelines  for  constructing  error-free  systems,  and  programming  techniques  for  evasion  of 
imminent  errors  at  runtime. 

In  this  paper  we  investigate  the  application  of  runtime  monitoring  methods  to  these  three  sub¬ 
problems.  Alternative  methods  of  eliminating  deadness  errors  based  on  static  analysis  at  compile 
time  are  not  addressed  in  this  paper.  So  far,  the  known  static  analysis  methods  are  very  difficult  and 
time-consuming  H'sylor  62]. 

In  Chapter  2  a  set  of  concepts  for  classifying  deadness  errors  in  Ada  tasking  is  defined.  These 
concepts  are  derived  from  the  informal  semantics  of  Ada  tasking  given  in  [Ichbiah  et  al.  82].  They 
form  a  complete  set  in  the  sense  that  an  operational  description  of  Ada  tasking  can  be  given  using 
only  these  concepts.  The  description  of  our  implementation  in  subsequent  chapters  is  based  on 
these  concepts.  However,  we  feel  that  our  present  set  of  concepts  should  be  treated  as  tentative.  It  is 
possible  to  define  other  complete  sets  of  concepts.  Alternative  concepts  with  advantages  over  the 
present  set  may  emerge  as  experience  in  this  area  accumulates. 

Our  monitor  system  has  two  parts:  (1)  a  separately  compiled  runtime  monitor  written  in  Ada.  and  (2)  a 
preprocessor  that  transforms  Ada  source  text  so  that  necessary  descriptive  data  is  communicated  to 
the  monitor  at  runtime.  The  result  of  applying  the  pre-processor  to  any  legal  Ada  program  is  a 
modified  program  which  is  again  a  legal  Ada  program  and  contains  the  monitor.  This  monitor  system 


is  intended  to  monitor  sufficient  information  about  tasking  activities  st  runtime  to  (i)  detect  a  very 
broad  class  of  deadness  errors,  and  (ii)  provide  descriptive  information  about  a  dead  state  when  it  is 
certain  that  the  state  will  occur,  and  prior  to  that  state  actually  occurring.  Some  of  the  basic 
transformations  and  an  abstract  monitoring  method  were  previously  described  in 
[German,Helmbold,Luckham  82].  This  established  the  essential  ideas  behind  our  implementation  but 
dealt  only  with  detection  of  deadness  and  applied  to  a  more  limited  class  of  errors. 

An  Ada  implementation  of  the  runtimo  monitoring  system  is  described  in  Chapter  3.  This  description 
encompasses  (a)  the  kind  of  descriptive  data  about  tasking  states  that  is  monitored,  (b) 
representation  of  the  descriptions  and  processing  to  detect  errors,  and  (c)  structural  design  of  the 
monitor.  The  monitored  data  must  be  sufficient  both  for  detection  of  deadness  and  for  providing 
diagnostics.  The  sctual  monitor  data  structures  and  procedures  must  correctly  implement 
representations  of  scheduling  states  (as  defined  in  Chapter  2);  any  monitor  procedure  must  always 
terminate,  preferably  as  quickly  as  possibie.  Structured  design  of  the  monitor  is  an  important 
consideration  both  for  runtime  efficiency  and  to  reduce  recompilation  if  the  monitor  system  is  altered 
for  a  special  application. 

C:,.  oter  4  describes  the  preprocessing  transformations  applied  to  Ada  source  text.  The  description 
deals  with  the  complete  set  of  transformations  that  are  currently  implemented.  These  transformations 
ensure  that  the  monitored  program  will  pass  sufficient  information  about  intended  tasking  operations 
(initiation,  rendezvous,  termination,  etc.)  to  the  monitor  to  enable  it  to  detect  a  wide  class  of  deadness 
errors,  including,  e.g.,  deadness  due  to  inability  of  dependent  tasks  to  terminate.  The  fine  details  are 
complex;  our  description  is  therefore  presented  informally  and  relias  on  illustiative  examples.  The 
preprocessor  is  implemented  in  SNOBOL. 

Chapter  S  deals  with  the  correctness  of  our  method.  By  this  we  mean  that  the  addition  of  the  monitor 
does  not  introduce  new  deadness  errors,  and  that  the  monitor  correctly  describes  an  error  when  it  is 
certain  that  the  error  will  occur  if  the  computation  continues  normally.  Discussion  of  these  issues  is 
informal  and  proofs  are  outlined.  Our  intention  here  is  to  indicate  how  a  formal  proof  can  be  given;  a 
fully  formal  treatment  is  beyond  the  scope  of  this  paper. 

The  monitoring  system  may  be  used  not  only  for  recognition  of  errors  but  also  for  evasive  action 
programming.  Enentially,  the  monitor  "knows”  a  deadness  error  is  certain  to  happen  (if  the 
computation  continues  normally)  before  it  occurs.  Warnings  (e.g.  Ada  exceptions)  may  therefore  be 
propagated  to  the  monitored  program  before  the  error  occurs,  thus  enabling  it  to  evade  the  error  by 
taking  some  abnormal  course  of  action.  Such  evasion  may  be  temporary  in  that  the  error  may 
become  imminent  again,  but  the  program  can  continue  useful  operation  for  a  time.  It  may  then  have 
to  evade  again,  and  so  on.  These  evasive  action  techniques  need  to  be  investigated  and  developed 
since  they  represent  a  very  useful  method  of  keeping  large  multi-tasking  programs  in  operation. 
Eventually  one  would  hope  to  be  able  to  determine  at  compile  time  that  such  programs  are  free  of 
deadness  errors,  but  until  the  necessary  theory  of  static  detection  is  developed,  evasive  action  may 
become  just  as  important  a  way  of  dealing  with  deadness  errors  as  testing  methods  are  for  most  other 
kinds  of  errors  today.  Indeed,  if  a  system  has  to  deal  with  unreliable  elements,  as  happens  in  many 
practical  applications,  evasive  action  techniques  could  become  a  standard  programming  practice. 

Some  techniques  for  evasive  action  programming  are  given  in  Chapter  6.  These  are  very  modest  and 
represent  just  a  beginning.  Examples  of  monitoring  experiments  for  debugging  and  evasive  action 
are  given  in  Chapter  7. 


The  current  experimental  monitor  is  programmed  in  Ada  and  compiled  using  the  Adam  compiler  at 
Stanford  [LUckham  et  al.^OAM  81].  Since  Adam  does  not  support  all  of  Ada82,  some  parts  of  the 
monitor  implementation  have  us^  circuitous  techniques.  This  is  especiaily  evident  in  our 
implementation  of  evasive  action;  warnings  are  implemented  by  means  of  extra  parameters  of  the 
monitor  entries  instead  of  exceptions  because  Adam  does  not  support  exception  propagation  during 
task  rendezvous. 

There  is  a  fundamental  philosophical  question  as  to  whether  such  monitoring  should  be  part  of  the 
runtime  supervisor  package  or  part  of  the  Ada  source  text  Basically,  it  is  too  early  in  the  development 
of  our  understanding  of  deadness  errors  to  take  a  stand  on  this  issue.  Both  approaches  have 
advantages.  Supervisor  monitoring  can  make  use  of  scheduling  information  already  present  in  the 
supervisor  and  therefore  does  not  dupUcate  this  information  at  runtime.  However,  p^aps  standard 
runtime  supervisory  packages  should  not  be  burdened  by  requirements  to  produce  debugging 
information  at  present,  especially  since  we  do  not  yet  know  what  information  is  adequate  in  general. 
Source  code  monitoring  has  many  advantages  such  as  the  sbiMy  to  tailor  deletion  information  and 
warnings  to  a  particular  application  program.  The  main  disadvantage  of  this  approach  lies  in  the  lack 
of  a  fundamental  task  identifier  type  in  Ada  itself,  but  this  is  a  problem  in  programming  other  resource 


scheduling  applications  in  Ada  too  [Luckham  et  al..AOAM  81]. 
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2.  DEFINITIONS 


2.1  TASK  STATUSES 

According  to  the  semantics  of  tasking  [ichbiah  et  al.  K]  a  task  miay  be  in  any  one  of  the  following 
statuses;  a  status  has  information  associated  with  it 

1.  Running:  a  task  in  this  status  may  be  run.  This  is  the  only  status  in  which  a  task  may  run. 

2.  Accepting:  a  task  t  is  watting  for  an  entry  eall  at  an  accept  statement  or  at  a  select 
statement  that  does  not  have  an  eise  dauae,  terminate  alternative,  or  a  delay 
aUsmative.  The  set  of  entries  baino  waHad  for  Q.e.,  the  entry  of  the  accept  or  those 
entries  corresponding  to  open  accept  aitamatives  of  the  aale^  ieassodatad  with  the 
accepting  status  of  t 

3.  Seleet'terminate:  a  task  t  is  at  a  select  statement  with  a  terminate  alternative;  the  set 
of  entries  corresponding  to  open  accept  alternatives  and  the  set  of  tasks  dependent  on  t 
are  associated  with  the  select*  terminate  status  of  t 

4.  Calling:  task  t  has  issued  an  entry  call,  s.e,  to  task  s,  which  is  neither  conditional  nor 
timed.  The  task  s  and  the  entry  e  are  associated  with  the  calling  status  of  t. 

5.  Block* waiting:  task  t  has  reached  the  end  of  an  inner  block  or  subprogram  and  is 
waiting  for  the  tasks  dependent  on  the  inner  block  to  terminate;  the  set  of  tasks 
dependent  on  the  block  or  subprogram  is  associated  with  the  block-waiting  status  of  t. 

6.  Completed:  task  t  has  completed.  The  set  of  tasks  dependent  on  t  is  associated  with 
the  completed  status  of  t. 

7.  Terminated:  task  t  is  terminated.  No  additional  information  is  associated  with  this 


8.  Seleet*Dependents>Completed:  task  t  is  at  a  select  statement  with  an  open  terminate 
alternative  and  all  dependent  tasks  have  reached  either  terminate  status  or  Select* 
Dependents-Completod  status.  The  set  of  entries  corresponding  to  open  alternatives  of 
the  select  statement  is  associated  with  this  status. 

Blocked:  A  task  in  any  of  the  statuses  2  *  8  is  said  to  be  btoekaO. 

This  set  of  statuses  and  associated  information  is  sufficient  to  describe  that  part  of  the  Ada  semantics 
of  task  rendezvous  that  determines  the  schedulabiiity  of  a  task.  Such  a  description  may  be  given  by 
means  of  a  status  change  diagram  indicating  how  the  semantics  of  rendezvous  determines  the  status 
changes  of  a  task.  Some  status  changes  of  task  t  are  d/recf  in  the  sense  that  the  action  of  t  itself 
causes  the  change;  other  changes  of  t  are  indiract  in  the  sense  that  they  are  caused  by  the  action  of 
another  task. 
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Oir«ct  Status  Changss: 
running  calling 

running  ••  accepting 
running  sa1act_tarfli1nata 
running  b1ock_wa1t1ng 

running  complatad 


Indirect  Changes: 
calling 
running 
accepting 
se1ect.te  nil  nets 
h1ock.«a1t 
set  ect_tsni1  nets 
se1eet_dapendents.coap1etsd 
se1eet.dependeats.coap1eted  <-» 
coaplated . 


running 

calling 

running 

running 

running 

select^dspendents.coapl sted 

ts  nil sated 

running 

tenelnated 


Notas: 

A  task  executing  a  delay  statement  is  in  status  ninning.  The  indirect  status  change  from  accepting  to 
running  occurs  when  the  entry  call  is  issued  rather  than  when  the  rendezvous  is  initiated.  A  task 
changes  from  status  running  to  calling  after  having  issued  a  conditional  or  timed  entry  call  only  if  the 
call  is  accepted  (this  status  change  is  therefore  indirect).  A  task  which  executes  a  select  statement 
will  usually  change  from  running  to  accepting.  A  task  which  executes  the  else  part  (or  delay 
alternative)  of  a  select  statement  remains  in  status  running. 


2.2  SCHEDULING  STATES  AND  OEAONESS  ERRORS 

For  a  given  input  a  program  P  may  have  many  different  possible  computations.  Each  possible 
computation  is  the  result  of  a  legal  Ada  scheduling  of  the  runnable  tasks.  Here,  the  word 
"scheduling"  is  used  in  a  very  broad  sense  to  reflect  simply  the  order  in  which  changes  of  status 
occur  among  the  individual  tasks  of  P.  Different  orders  may  result  from  different  scheduling 
algorithms  for  multiplexing  tasks  on  a  single  CPU,  or-  from  differing  speeds  of  CPU’s  in  a 
multiprocessor  system.  The  details  of  the  underlying  scheduling  do  not  concern  us  in  this  paper.  We 
are  concerned  only  with  observable  differences  in  the  sequence  of  status  changes.  It  should  be 
noted  that  different  schedulings  may  result  in  different  outputs  from  the  computation,  e.g.  in  the  case 
where  P  is  monitoring  its  own  status  changes. 

Task  ldentifiers.Each  task  that  is  activated  during  a  computation  of  program  P  is  assigned  a  unique 
name  called  its  idantifiar.  It  is  assumed  that  a  task  can  access  its  own  identiEer  and  the  identifier  of 
any  task  that  is  visible  to  it 

Task'Status  Pairs.  A  taak^atatua  pair  is  sn  ordered  pair  consisting  of  a  task  identifier  as  first 
element  and  a  status  as  second  element  (notation:  <t,s>). 

Scheduling  States.  A  aehaduilng  atata  of  a  program  P  is  a  set  of  task-status  pairs  such  that  each 
task  of  P  is  the  first  element  of  exactly  one  pair.  If  <t,s>  is  a  member  of  state  S,  then  task  t  has  status 
sinS. 
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Exseution.  An  axteution  of  P  is  a  aequsncs  of  pairs  consisting  of  a  task  idsntifisr  and  a  saquSnca  of 
sitnpio  statamsnts  such  that 

1 .  ths  task  idsntiner  of  ths  first  pair  identifiss  ths  main  program; 

2.  ths  task  idsntifler  of  ths  nth  pair  <t^,  c^>  has  status  running  as  a  rssult  of  the  execution 
of  the  statements  in  the  previous  pairs  by  the  named  threads  of  control; 

3.  As  a  consequance  of  the  execution  of  the  statements  in  the  previous  pairs  in  the 
aaquence  by  the  named  thraada  of  eontrot,  may  legaiiy  execute  the  simple  statements 
in  in  that  order,  and  Ha  status  does  not  change  until  possibly  after  the  last  statement  of 


Not99t 

Executions  correspond  to  computations  of  P  on  a  single  CPU.  An  execution  is  an  interleaving  of  the 
sequences  of  simple  statements  executed  by  the  running  threads  of  control:  it  is  convenient  to 
consider  end  as  s  simple  stalsment  in  the  definition  of  execution. 

Statements  appear  in  executions  in  positions  corresponding  to  their  normal  termination.  For 
example,  if  task  t  calls  procedure  p.  then  the  simple  statements  executed  during  p's  execution  will 
appear  in  an  execution  pair  for  t  before  the  procedure  call.  Since  a  change  of  status  from  running 
occurs  during  execution  of  a  tasking  statement,  and  possibly  back  to  running  again  at  the 
completion  of  that  statement,  tasking  statements  will  appear  at  the  beginning  of  sequences  in  pairs. 
The  subsequence  of  pairs  representing  a  single  task's  executions  contains  simple  statements  that  the 
task  must  execute  in  a  (according  to  Ada  semantics)  legal  order  of  execution. 

An  execution  can  be  constructed  from  an  actual  computation  in  the  obvious  way  by  writing  down  the 
identifier  of  the  running  thread  of  control  at  any  time  followed  by  the  simple  statements  that  it 
executes.  Conversely  any  execution  corresponds  to  an  actual  computation  on  a  single  CPU  under 
some  scheduling.  Since  the  semantics  of  Ada  is  independent  of  the  number  of  CPU’s,  definitions 
based  on  this  imposed  linearization  of  tasking  computations  are  valkl  generally  for  any  metiiod  of 
scheduling  computations. 

The  concept  of  execution  described  here  can  be  given  a  formal  definition  in  terms  of  transition  rules 
similar  to  the  operational  semantics  for  Ada  in[U  82].  We  may  therefore  use  the  notions 
"computation"  and  "execution"  interchangeably  in  the  following  discussion. 

Scheduling.  A  eeheduHng  is  an  activity  which  may  change  the  execution  sequence  associated  with  a 
computation-of  P  given  a  fixed  input 

Notee: 

This  concept  of  scheduling  is  very  broad.  It  includes  the  implementation  of  the  select  statement, 
relative  speeds  of  processors,  computations  of  the  runtime  host  snvironment,  I/O,  and  any  other 
activity  that  may  change  the  order  in  which  different  threads  of  control  change  statuses. 

A  program  P,  given  a  fixed  input  may  have  many  different  possible  computations,  each  of  which  is 
the  result  of  a  change  of  scheduling. 

Sequenees  of  Scheduling  States  A  computation  of  program  P  has  an  associatsd  linear  sequence 
of  scheduling  states.  All  tasks  are  activated  in  running  status.  Each  new  stats  in  the  saqusncs  results 
horn  the  previous  state  by  a  status  change  by  one  task.  Simultaneous  status  changes  are  ordered 
arbitrarily;  an  imfireet  status  change  follows  the  status  change  of  the  task  causing  it 

Oeadness  Error.  A  deadnest  error  is  a  scheduling  state  occurring  in  a  computation  of  P  in  which  a 
subset  of  tasks  are  in  bloeked  ttstusss  but  not  terminated,  and  there  can  be  no  subsequent 
scheduling  stats  in  a  posaibie  continuation  of  that  computation  of  P  from  that  state  in  vrhich  the 
statuses  of  the  subset  have  chwgsd. 


PoUntiai  0«adn«ss  Error.  A  program  P  has  a  potential  deadnasa  error. if  there  is  an  input  and  a 
possible  computation  such  that  the  assodatsd  sequence  of  states  contains  that  error. 

Notaa: 

A  biocKed  state  is  a  scheduling  state  in  which  no  task  has  status  running,  no  (indirect)  status  changes 
are  possible,  and  not  every  task  has  status  terminated. 

A  deadlocked  state  is  one  in  which  a  subset  of  tasks  are  ail  in  status  calling  and  the  calls  are  to  entries 
of  membeia  of  the  subset 

Oeadness  arrora  indurto  global  bioeking  in  which  alt  tasks  are  biocksd,  circular  deadlock,  and  errors 
arising  whsn  subsets  of  tasks  block.  Implementation  dependent  orrois.  e.g.  tailure  of  an  entry  call  to 
be  sorvieed  due  to  a  partieular  implementation  of  arUtrary  sslectfon  (starvation),  are  not  included. 


2.3  MONITORED  PROGRAMS 

Runtime  monitoring  for  deadness  errors  involves  adding  a  monitoring  task  M  to  a  given  program 
P.  The  text  of  P  is  transformed  so  that  tasks  have  unique  identifiers  and  may  identify  each  other  and 
communicate  status  changes  to  M.  The  resulting  program,  P’,  is  called  a  monitored  program.  It  is 
important  to  establish  that  the  addition  of  M  to  P  (to  form  P')  does  not  change  the  set  of  potential 
deadness  errors  of  P. 

The  next  set  of  definitions  are  made  in  order  to  establish  a  sense  in  which  two  programs  P  and  P'  can 
be  said  to  possess  the  same  potential  deadness  errors.  As  a  special  case  we  define  what  is  meant  by 
saying  that  the  same  deadness  error  occurs  in  two  distinct  computations  of  P.  These  definitions  are 
complicated  by  the  possible  dynamic  creation  of  tasks  in  Ada  and  corresponding  dynamic  allocation 
of  task  identifiers. 

correspondence:  We  assume  there  is  a  textual  correspondence  between  P  and  P'  such  that 

1.  every  declaration  in  P  corresponds  to  a  declaration  in  P’  of  the  same  kind, 

Z  every  object  in  P  corresponds  to  an  object  (or  component  object)  in  P*  of  the  same  kind, 

Z  every  statement  in  P  corresponds  to  a  statement  in  P*  of  the  same  kind, 

4,  the  correspondence  is  consistant  i.e.,  declarationa  and  statements  in  a  program  unit  U  in 
P  correspond  to  declarationa  and  statements  in  the  corresponding  program  unit  U*  in  P*. 

Notes: 

Any  object  declared  in  P  corresponds  to  an  object  declared  in  P*  of  the  same  kind,  in  particular  tasks 
correspond  to  tasks.  However,  not  every  declaration  or  statement  in  P’  need  have  a  correspondence 
inP. 

Corresponding  Executions.  Let  E  aial  E*  be  executions  of  P  and  P*  respectively.  Assume  there  is  a 
textual  correspondence  between  P  and  P*.  Then  E  and  E’  correspond  if  all  task-code  pairs  of  E  can 
bo  placed  in  a  correspondence  with  task-code  pairs  in  E  according  to  the  following  inductive  test 
Suppose  that  the  first  n  pairs  of  E  correspond  to  pairs  On  the  same  order)  among  the  first  m  (m  ^  n) 
pairs  of  E’.  and  that  there  is  a  one*one  correspondence  between  all  the  task  identifiers  that  have 
occurred  so  far  in  E  and  a  subset  of  those  in  E*.  Lot  the  nth.  and  mth.  pairs  be  <t.,  c,.>  in  E  and  <t., 

o  n  in' 


1.  if  ail  the  statamenti  of  are  in  (i-i)  correspondence  (under  the  textual  relationahip 
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betwMn  P  and  P')  with  the  statements  of  in  the  same  order,  then  and  must 
correspond.  If  neither  yet  corresponds  to  any  task,  they  are  placed  in  correspondence  (in 
E  and  E’),  and  the  test  proceeds  to  the  next  pairs  in  E  and  E’; 

Z  If  no  statement  in  c^  has  a  textuaity  corresponding  statement  in  P  then  <t^,  c^>  is 
compared  with  the  next  pair  in  E‘: 

a  If  neither  of  the  first  two  cases  holds  then  the  correspondence  test  fails. 

Notts: 

If  two  executions  E  and  E*  eorraepond  then  Om  task  idantmefs  in  E  are  In  one~one  correspondence 
with  a  subsst  of  the  task  identifiers  in  E*.  H  t  in  E  corresponds  with  f  in  E*  then  t  executes  code 
corresponding  to  some  of  the  code  executed  by  t*.  possibly  interspersed  with  code  in  E’  which  has  no 
correspondence  in  E  ThuSi  in  a  general  sense  corresponding  task  identifiers  are  names  for  threads 
of  control  that  execute  the  same  aubcomputations.  (restricted  to  statements  of  P).  E*  may  have  tasks 
that  do  not  correspond  to  any  task  in  E;  this  is  a  consequence  of  the  assumption  that  the  textual 
correspondence  between  P  and  P*  is  "Into*.  Le..  P*  may  be  "bigger”  than  P. 

Equivalent  Scheduling  States.  If  E  and  E'  are  corresponding  executions  of  P  and  P*  then 
scheduling  state  S  of  E  is  equivalent  to  a  scheduling  state  S'  of  E'  if  for  every  task -status  pair  <t,  s> 
in  S  the  task -status  pair  <t',  s>  is  in  S'  where  t  and  t'  correspond  in  E  and  E',  and  all  other  tasks  of  S' 
are  blocked. 

Same  Potential  Errors.  P  and  P*  have  tho  same  potential  deadness  errors  if  for  every  potential 
deadness  error  of  P  occurring  in  execution  E.  there  is  a  corresponding  execution  E'  of  P'  in  which  an 
equivalent  deadness  error  occurs,  and  conversely. 

Notes: 

"Conversely"  means  the  following:  if  a  deadness  error  S'  occurs  in  execution  E'  of  P'  then  there  is  an 
execution  E  of  P  such  that  E  and  E'  correspond  and  a  deadness  error  S  equivalent  to  S'  occurs  in  E. 

Non  Interference.  A  task  M  is  said  not  to  interfere  with  a  program  P  if: 

1.  its  addition  to  P  forme  a  legal  Ada  program  P'  and  dafinea  a  textual  correspondence 
between  P  and  P*. 

2.  P  and  P'  have  the  same  set  of  potential  deadness  errors. 

Notes: 

M  does  not  interfere  with  P  if  md  only  if  its  (legal)  addition  to  P  does  not  introduce  any  new  potential 
deadness  errors  nor  remove  any  potential  deadness  errors. 

The  definition  of  non-interference  is  weak  in  the  sense  that  P  and  P*  are  not  required  to  compute  the 
same  values  or  to  be  equivalent  in  any  of  the  usual  sansas.  The  terminology  "addition  to  P"  is  left 
undefined:  it  may  involve  changes  to  the  text  of  P  as  well  as  the  addition  of  the  text  of  M;  it  is  required 
that  the  "addition”  sets  up  a  textual  correspondence  between  P  and  P*. 
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3.  DEADNESS  MONITOR. 


Th«  monitor  dotacts  doadnoas  orrors  baaod  on  Information  racaivad  from  the  praprocassad  program. 
In  our  Implamantation  this  information  consists  of  changes  of  statuses  and  associated  information 
(see  Section  2).  The  monitor  maintains,  throughout  the  execution  of  the  modified  program,  a 
"pietura"  of  the  program’s  scheduling  stats.  This  picture  is  generally  updated  and  checked  for 
deadnaaa  errors  whenever  information  is  receivod  from  the  program,  in  addition  to  detecting 
daedneaa  errors,  the  ntonitor  alao  providaa  tedWaa  for  tracing  status  changes,  querying  the  current 
"picture"  and  undertaking  ewaaiwe  action  to  avoid  a  daadnaas  error. 


3.t  TW  MONITOR'S  SmUCTUm 


Our  monitor  is  impiementad  in  two  parts,  a  task  and  a  package.  The  task  is  inserted  into  the  program 
by  the  preprocessor  The  package  is  designed  to  be  compiled  separately:  it  contains  the  monitor's 
data  structure  and  the  procedures  that  act  upon  it  This  organization  allows  separate  compilation  as 
well  as  protecting  the  monitor  from  simultaneous  access. 

The  package  is  separated  from  the  program  for  efficiency  reasons.  It  is  compiled  only  once,  and  then 
linked  each  time  a  program  requires  it  Even  if  several  programs  are  using  the  monitor,  only  one  copy 
of  the  monitor  needs  to  be  kept  on  disk.  Separately  compiling  the  monitor  also  eases  the  burden  on 
the  compiler,  the  AOAM  compiler  had  troubiea  dealing  with  the  monitor  and  a  mederate  sized 
program  at  the  same  time. 

The  monitor  task's  main  purpose  is  to  transmit  data  to  the  monitor  package.  The  preprocessed 
program  communicates  the  status  change  information  to  the  task  via  the  Ada  rendezvous 
mechanism.  The  task  then  calls  the  appropriate  procedure  of  the  monitor  package.  Buffering  the 
information  through  a  task  in  this  way  anaures  that  only  one  thread  of  control  (the  monitor  task)  can 
update  the  monitor's  data  structure  at  a  time.  The  monitor  task  also  seems  to  provide  a  convenient 
place  to  customize  the  monitor  for  a  epec^  application,  since  the  monitor's  internal  workings  are 
hidden  in  the  package.  We  have  created  an  intaraetive  version  of  the  monitor  in  this  manner. 


Structure  Oudbie: 


package  NONITOII.OATA.kACKAGC  la 


procedure  ACCCATIM  (SERVER 

ERTRY.RAME 

OEAOLK.FLAG 


Oats  afruefures  omhfd 
:  in  TASK.IO; 

:  in  STRING: 

:  out  BOOLEAN); 


procedure  UNBLOCK  (SUBJECT  :  in  TASK.ID); 
end  IIONITOR.OATA.RACKAGE: 

task  body  MONITOR  is 
b#Qlfi 

MONITOR.DATA.PACXAGE .  INIT ;  —  /n/ffa/fze  the  monitor  peekege. 

while  not  MON ITOR.OATA.PACKAGE. DONE  loop 

Loop  until  all  othor  taaMa  havo  tarmlnatad. 
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—  Simply  accept  a  call  from  the  program  and 
—  relay  the  information  to  the  monitor. 

aceapt  ACCEPTING  (SERVER  :  in  TASK.IO; 

ENTRY.NAME  :  in  string; 

DEAOLK.FLAG 

MONITOR.DATA.PACICAGE .ACCEPTING  ( SERVER . 

ENTRY.NAME . 
DEAOLK.FLAG): 

and; 

•  •  • 

■  •  ■  or  . 

aoeopt  UNBLOCK  (SUBJECT  :  in  TASK.ID)  do 
MONITOR.OATA.PACKAGE. UNBLOCK  (SUBJECT); 

and; 

and  salaet  ; 
and  loop ; 
and  MONITOR; 


3.2  THE  MONITOR'S  PICTURE 

Tha  monitor  maintains,  at  runtima,  a  pictura  of  tha  program’s  scheduling  state.  This  picture  consists 
of  status  and  associated  information  for  each  task,  entry  point  information,  dapandancy  information, 
and  saverai  global  (to  the  monitor  package)  counters.  This  picture  is  incomplete  in  that  it  does  not 
reflect  any  interactions  with  tha  monitor  task.  Alt  calls  to  the  monitor  task  are  assumed  to  be  promptly 
answered  and  completed.  Tha  picture  may  not  even  t>e  strictly  accurate  as  calls  to  the  monitor  may 
be  ser/icad  in  an  order  other  than  that  in  which  the  status  changes  occur. 


3.2.1  TASK  aiPOmiATION 


Each  activated  task  of  die  original  program  is  raprasontad  by  a  record  in  the  monitor's  data  structure. 
TMa  record  contains  status  and  other  information  pertaining  to  the  task. 

type  TASK.RECORO  is 


Bach  task  will  have  a  record  of  this  type  to 
hold  information  associated  with  the  task. 


record 

TASK.NAME 

STATUS 

CALLEO.TASK 

CALLEO.ENTRY 


MON.NAME.TYPE; 

—  A  user-defined  output  name. 
TASK.STATUS; 

The  status  of  this  task. 

TASK.ID; 

The  task  that  this  task  has  issued  an 
—  entry  caii  to. 

MON_NAI*E.TYPE; 
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Tht  tntry  b»ing  etll0d. 


PAREMT.TASIt  ;  TASIC_IO; 
OEPENOENTS  :  lO.PTR; 
NUN_UAIT_FOR  :  INTEGER: 


LIST_PTR  :  ENT.PTR: 

TRACE  :  BOOLEAN; 


«fHl  r«card; 


Tht  task  that  this  one  dapsnds  on. 

4  i/st  of  tasks  dapanding  on  this  task. 

Tha  numbar  of  tasks  that  naad  to  finish 
batora  this  ona  can  proceed. 

A  pointar  to  tha  Uat  of  antriaa  in  this  task. 

Trua  fFF  traea  Intomatfon 
on  this  task  fa  to  ba  printad 


The  lint  field  eonteine  the  taek  name.  This  string  is  used  only  to  identify  the  tMfc  to  the  user,  and  hss 
no  internal  meaning.  The  second  field  contains  the  task's  status  (see  Section  2.1).  The  next  two 
fields  contain  associated  information  for  status  calling;  the  task  and  entry  called.  Following  these  are 
fields  containing  dependency  information:  a  list  of  dependent  tasks  that  this  task  is  waiting  on:  the 
number  of  those  tasks  that  have  not  terminated:  and  this  task's  parent  (see  3.2.3).  An  additional  field 
holds  a  pointer  to  the  list  of  entries  associated  with  the  task.  The  last  field  contains  a  flcj  indicating 
whether  or  not  the  task's  status  changes  should  be  traced.  These  records  are  stored  in  an  array,  and 
indexed  by  task  IDs. 


3.S  Jl  OITRY  INFORMATION 

The  monitor  creates  entry  records  for  each  entry  point  as  it  finds  out  about  them  (i.e..  just  before  they 
are  referenced  at  call,  accept  and  select  statements).  These  records  contain  the  unique  string 
representation  for  the  entry  cretfiod  by  the  preprocessor,  the  number  of  tasks  calling  the  entry  and  a 
HERE.FLAG,  indicating  if  the  task  is  currendy  waiting  for  (ready  to  accept)  a  ceil  to  the  entry.  All  of 
the  records  for  a  task's  entries  are  stored  in  an  unordersd  linked  list  referenced  from  the  task's 
record. 


S.2.3  OCPINOfNCY  WPORMATION 

Keeping  track  of  dependency  infprmation  poses  special  probisms  for  the  monitor.  According  to  the 
Ada  semantics,  each  tsak  dTrsetty  depends  on  some  master  (a  block,  subprogram,  task,  etc.).  This 
masisr  is  usually  the  scope  where  the  tsak  is  daciarsd,  however  tasks  creaMd  by  an  allocator  call 
depend  on  the  scops  where  the  access  type  was  dsciared. 

We  define  the  sona  of  task  t  (or  main  program)  to  be  those  tasks  which: 

1.  directly  depend  on  t; 

2.  directly  depend  on  one  of  t's  inner  blocks;  or 

3.  directly  depend  on  a  subprogram  (or  subprogram  Inner  block)  elaborated  by  t. 


if  task  e  is  the  SON  of  task  L  tfwn  tuk  t  is  the  fathar  of  task  s.  This  father-son  relationship  forma  a  tree 
structure. 
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The  preprocessor  inserts  declarations  for  a  list  of  directly  dependent  tasks  in  each  block,  task  and 
subprogram  of  the  original  program  (see  Section  4.3).  An  additional  list,  containing  ail  of  the  task's 
sons,  is  declared  in  each  task  body.  When  new  tasks  are  created,  their  IDs  are  added  to  the 
appropriate  lists  during  the  A0D_0EPEN0ENTS  monitor  call. 

When  task  t  is  ready  to  terminate,  it  passes  the  list  of  all  its  sons  to  die  monitor.  The  monitor  sets  the 
PARENT.TASK  Reid  in  the  task  record  of  each  task  on  the  list  to  t’s  ID.  The  monitor  stores  the  number 
of  sons  that  have  not  yet  finished  in  the  t‘e  NUNJMIT.POR  Held. 

By  checking  to  see  tf  task  t*s  NUN.WAIT.FOR  lloid  is  0,  the  monitor  can  easily  see  if  all  the  sons  of  t 
have  finished.  When  this  occurs,  task  t  is  terminated,  along  with  all  of  ita  sons  still  at  select 
statements  with  terminate  aitamativea.  The  monitor  then  checks  the  FATHER  field  for  task  t.  If  it  is 
non-empty  (contains  a  valid  task  10)  then  the  PARENT.T ASIC’s  NUMJWAIT.FOR  count  is  decremented. 

The  same  algorithm  is  used  when  a  task  attempts  to  leave  a  block,  except  that  the  list  of  dependents 
contains  only  those  tasks  that  directly  depend  on  the  block. 

Notes: 

It  is  important  to  set  the  PARENT^TASK  field  of  a  task  only  when  the  father  is  waiting  on  that  task. 

Otherwise,  the  task  may  decrement  the  PARENT _ TASK’S  MUM_WAIT _ FOR  count  before  the 

PARENT_TASK  is  waiting  for  it  (e.g*.  if  the  father  was  waiting  on  an  inner  block). 

It  is  important  to  have  the  monitor  modify  these  lists  of  dependents.  When  a  task  is  attempting  to 
terminate,  it.  passes  the  monitor  a  list  of  it's  dependents.  If  some  other  task  creates  a  new  dependent 
of  the  first  task,  then  the  change  in  the  list  of  dependents  must  be  communicated  to  the  monitor.  The 
monitor  checks  for  this  situation  whenever  it  updates  a  dependency  list.  The  monitors  mutual 
exclusion  properties  are  used  to  ensure  that  two  tasks  are  never  simultaneously  updating  a 
dependency  list. 


S.2.4  OLOBAL  variables 

Three  variables  are  used  to  enable  the  monitor  to  efficiently  detect  globe!  blocking.  The  monitor 
maintains  counts  of: 

1.  the  number  of  tasks  that  have  been  activatsd; 

2.  the  number  that  are  blocked;  and 

3.  the  number  that  have  terminated. 

If  the  number  of  tasks  that  are  terminated '«  equal  to  the  number  of  tasks  that  have  been  activated 
then  the  program  has  terminated.  Otherwise,  if  the  number  of  tasks  that  are  blocked  is  equal  to  the 
number  of  tasks  that  have  been  activated,  then  global  blocking  has  occurred.  These  checks  are  done 
every  time  a  task  becomes  blocked  in  the  monitor's  picture  (for  any  reason). 

An  additional  boolean  variable.  DONE,  is  used  to  inform  the  monitor  task  that  ail  of  the  other  tasks 
have  terminated.  This  variable  is  declared  in  the  visible  part  of  the  monitor  package  so  it  can  be 
examined  by  the  monitor  task. 

Below  is  the  visible  part  of  the  monitor  package  and  the  specification  for  the  monitor  task. 


Data  strueturaa  used  by  the  monitor. 
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(10  oe  compiled  separately.) 
Adam  I/O- package. 


wtth  OTTY.IO 

paekag*  MONITOR.OATA.PACKAGE  ia 


Bounds  and  data  structures  used  Oy 
the  monitor. 


STRIilG.LENGTH  :  eonatant  INTEGER  5; 

MAX_NUM.TASKS  :  eonatant  INTEGER  :>  IS; 

TASK.LIMXT  :  constant  INTEGER  :>  (MAX.NUM.TASKS  <  1): 


aubtypa  TASK.IO  la  INTEGER  range  -  1  ..  TASK.LIMIT; 
ALL.rASX5  :  eonatant  TASK.I0  -  1; 

NULL.TASI(  :  eonatant  TASK.I0  -  1; 

aiibtyfM  M)N.NANE.TYPE  laatring  (l  ..  STRING.LENGTH) ; 
NULL.IIAME  :  eonatant  MON.NANE.TYPE  :>  -NNIL#*: 


typo  ENTRY.REC: 

typo  EMTRY_PTR  is  aeeoss  MON.ENT.REC; 
typo  EMTRY_REC  is 
record 

NAME  :  MOM_NAME_TYPE; 

NEXT  :  ENTRY.PTR: 
and  record: 

Used  to  pass  the  monitor  lists  of 
~  entry  points. 

typo  lO.REC; 

typo  ID.PTR  is  aeeoss  mom^IO_REC; 
typo  lO.REC  is 
record 

ID  :  TASK.IO; 

NEXT  :  IOi.PTRT 

Used  to  pass  the  monitor  lists  of 
—  task  ID'S 


end  record: 


Monitor  package  procedures  are  omitted 
sinee  they  correspond  one — one  with 
monitor  task  entries  described  below. 


DONE  :  BOOLEAN  FALSE: 
end  MONITOR.OATA.PACKAGE: 


The  DEADLOCK  MONITOR  task  itself. 
(This  ia  inserted  into  P.) 


use  MONITOR.OATA_PACKAGE; 
task  MONITOR  is 


Group  1  below  are  called  to  notify  the 
monitor  of  status  changes  that  are  about 
to  take  place  of  activation  of  new  tasks, 
and  of  task  dependencies  (see  Section  3. 1). 


entry  NEWT  ASX  (TASK.NAME  :  in  string: 

NEW.IO  :  out  TASK.I0); 
entry  A00.0EPEN0ENT( FATHER  :  in  TASX_I0: 
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SON  :  In  TASK.ID); 

LISTI  :  in  out  I0_PTR; 

LIST2  ;  in  out  I0_PTR; 

•ntry  CALLING  (CONSUMER  :  in  TASK.IO: 

SERVER  :  in  TASK_ID; 

ENTRY_NAME  :  In  STRING: 

OEAOLK_FLAG 

•ntry  ACCEPTING  (SERVER  :  in  TASK.IO; 

ENTRY  NAME  :  in  STRING]; 

0EA0LIC.FLA6 

•ntry  SELECTING  (SERVER  :  bi  TASK_ID: 

ENTRY_L1ST  r  in  out  ENTRY_PTR; 

TERMINATE.FUG  :  in  BOOLEAN; 

OEPENOENTS  :  in  ID.PTR; 

OEAOLK.FLAG  :  out  BOOLEAN); 

•ntry  START.RENOEZVOUS  (CONSUMER  :  in  TASK.ID; 

SERVER  ;  in  TASK_ID; 

ENTRY.NAME  :  in  STRING); 

•ntry  ENO.RENOEZVOUS  (CONSUMER  :  in  TASK.IO; 

SERVER  :  in  TASK.ID; 

ENTRY_NAME  :  in  STRING); 

•ntry  EN0_8L0CK  (CONSUMER  :  in  TASK_ID; 

OEPENOENTS  :  in  ID_PTR; 

OEAOLK_FLAG 

•ntry  ENO  TASK  (CONSUMER  :  in  TASK.IO; 

OEPENOENTS  :  in  IO_PTR; 

OEAOLK.FLAG  :  out  BOOLEAN): 

—  Group  2  provides  some  facilities  for 
—  tracing  statuses  and  seneduiing  states. 

entry  PRINT; 

•ntry  TRACE  (SUBJECT  :  in  TASK.D; 

FLAG  :  in  BOOLEAN); 

*—  Group  3  is  used  to  facilitate  evasive  action. 
•ntry  QUERY  (SUBJECT  :  fn  TASK.ID; 

CALLEO.TASK,  ENTRY.CALLED  :  out  string; 

WAITING  AT  :  out  ENTRY_PTR)  ;• 

•ntry  UNBLOCK  (SUBJECT  :  in  TASK.IO); 

•nd  MONITOR; 


3.3  STATUS  CHANGES 

Calls  to  the  majority  of  monitor  entries  are  placed  in  the  original  program  according  to  the 
transformation  rules  given  in  Section  4.  These  calls  notify  the  monitor  of  impending  status  changes, 
and  any  associated  information  (as  defined  for  each  status  in  Chapter  2).  Such  calls  typically  involve 
modifying  the  monitor's  picture.  Below  we  describe  the  necessary  action  that  the  monitor  must  take 
on  each  call. 

Evasive  action  in  this  implementation  must  make  use  of  the  DEA0LK_FLA6  formal  parameter  of  entry 
calls.  All  monitor  calls  which  can  block  the  task  issuing  the  call  have  a  BLOCKED_STATE_FLAG  actual 
parameter  in  addition  to  those  mentioned  below.  This  flag  is  returned  with  the  value  true  if  and  only  if 
a  blocked  state  results  in  the  monitor's  picture  from  the  call.  For  more  details  on  evasive  action  see 
Section  6.  The  OEAOLK_FLAG  parameter  will  be  ignored  for  the  remainder  of  this  section. 
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Th«  NEWTASK  entry  informs  the  monitor  that  another  task  has  been  created.  The  monitor  creates  a 
new  task  record,  initiaJizing  it  with  the  passed  task.name  and  status  running.  The  remaining  fietds  are 
set  to  null  values.  The  record  is  stored  in  the  next  available  position  in  the  array.  The  index  where  it 
is  stored  is  returned  as  the  N£U_I0. 

Notes: 

Task  ID’S  cannot  be  implemented  by  access  type  objects  accessing  task  objects  because  of  the 
strong  typing  of  Ada.  The  monitor  type  declarations  would  have  to  be  changed  (and  the  monitor 
recompiled)  for  each  monitored  program  P.  The  task  type  declarations  of  P  would  have  to  be  placed 
in  the  most  global  declarative  part  and  still  the  problem  of  a  task  being  able  to  find  its  own  name 
would  remain. 

The  AOO  —  DEPENDENT  entry  ia  used  to  put  tasks  on  dependency  lists.  When  the  monitor  receives 
this  call,  it  places  SON  on  the  two  lists.  If  one  of  the  LISTs  is  a  part  of  the  PARENT'S  associated 
information,  then  the  DEPENDENTS  list  and  the  NUM_WAIT_FOR  count  in  the  PARENT'S  record  are 
updated  accordingly. 

The  CALLING  entry  is  used  to  tell  the  monitor  that  a  task  is  about  to  issue  an  entry  call.  When  the 
monitor  accepts  this  entry  it  undertakes  the  following  actions: 

1.  Change  the  CONSUMER’S  status  in  the  monitor’s  picture  from  Running  to  Calling. 

2.  Increment  the  queue  size  (in  the  monitor's  picture)  associated  with  the  called  entry. 

3.  If,  in  the  monitor’s  picture,  the  SERVER  is  in  status  Accepting,  Select_Terminate.  or 
Select.Oependents.Completed,  and  it  is  waiting  on  the  called  entry  then  the  SERVER'S 
status  is  changed  to  Running  and  the  NUM_3L0CkED  count  is  decremented. 

4.  The  NUM_BLOCKED  count  is  incremented  due  to  the  consumer  becoming  blocked. 

The  ACCEPTING  entry  is  used  to  inform  the  monitor  that  a  task  is  about  to  execute  an  accept 
statement.  Upon  receiving  this  call  the  monitor  examines  the  queue-size  for  this  entry.  If  it  is  zero, 
then  the  SERVERS  status  is  changed  to  Accepting,  the  HERE_FLAG  for  the  entry  is  set,  and 
NUM.BLOCKEO  is  incremented. 

SELECTING  is  called  when  a  task  is  about  to  execute  a  select  statement,  which  may  contain 
terminate  alternatives,  as  well  a  rtumber  of  open  accept  alternatives  (see  Section  4.4.3).  The 
ENTRY_LIST  parameter  contains  a  list  of  ail  the  entries  that  can  be  accepted.  The  DEPENDENTS 
parameter  holds  a  list  of  all  the  task'ssons.  The  TERMINATE_FLAG  parameter  will  be  true  only  if  there 
is  an  open  terminate  alternative.  If  some  of  the  entries  on  ENTRY_LIST  have  non-empty  queues  (in 
the  monitor's  picture),  then  the  SERVER  remains  in  status  Running.  Otherwise,  the  HERE_FLA6s  for 
ail  the  entries  on  the  list  are  set  and  the  TERMINATE^FLAG  is  checked.  If  it  is  true,  then 

1.  The  SERVER  is  placed  in  status  Seiect.With.Terminate. 

2.  The  SERVER'S  DEPENDENTS  field  is  set  to  the  passed  DEPENDENTS  list 

a  If  the  SERVER'S  PARENT.TASK  Reid  contains  a  valid  ID,  then  the  PARENT_TASK's 
NUM_WAIT_FOR  count  is  decremented  and  checked  for  0. 

If  the  TERMtNATE.FLAG  is  false,  then  the  SERVER  is  put  into  status  Accepting.  If  the  SERVER  is  now 
blocked,  then  NUM.BLOCKEO  is  incremented. 

The  START.RENDEZVOUS  entry  is  called  at  the  start  of  all  the  original  accept  bodies  of  P.  Upon 
receiving  this  call  the  monitor  does  the  following: 
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1.  If  the  CONSUMER  is  not  in  status  Calling  (e.g.  because  it  issued  a  conditional  or  tinred 
entry  call)  ttien  .the  actions  for  entry  CALLING  are  taken.  This  ntay  cause  the  SERVER  to 
change  status  from  Accepting  to  Running. 

2.  The  queue  size  associated  with  the  entry  point  is  decremented. 

3.  All  of  the  HERE_FLAGS  for  the  SERVER’S  entries  are  cleared,  as  the  server  is  no  longer 
waiting  at  any  entry. 

When  receiving  the  ENO.RENOEZVOUS  entry  the  monitor  simply  changes  the  status  of  CONSUMER 
back  to  Running  and  decrements  the  NUM.BLOCKEO  counter.  The  server  parameter  is  included  for 
tracing  purposes. 

The  ENO_BLOCK  entry  hae  parameters  CONSUMER  (the  task  leaving  the  block)  and  OEPENOENTS,  a 
list  of  tasks  which  are  dependent  on  the  scope  being  left.  If  some  of  the  OEPENOENTS  have  not 
terminated,  the  monitor 

1.  Sets  the  FATHER  field  for  each  task  on  the  DEPENDENTS  list  to  the  CONSUMER. 

2.  Sets  the  CONSUMER'S  NUM_WAIT_FOR  field  to  the  number  of  tasks  on  the  DEPENDENTS  list 
that  have  not  finished. 

3.  Sets  the  CONSUMER'S  status  to  Block.Wait. 

4.  Increments  the  NUM_BLOC'<ED  counter. 

The  END_TASK  entry  is  similar  to  the  END_BL0C1C  entry,  except  the  CONSUMER  is  placed  in  status 
Completed  rather  than  Block.Wait. 


3.4  DEBUGGIMG/TRACE  ENTRIES 

These  entries  are  used  to  control  diagnostic  output  for  the  monitor,  and  are  placed  by  the 
programmer  in  either  the  original  or  transformed  Ada  source  code. 

PRINT  has  no  parameters.  When  the  monitor  accepts  this  entry,  it  prints  out  its  internal  picture. 
Using  this,  a  programmer  can  get  "snapshots”  of  scheduling  states  during  a  computation. 

A  call  to  the  monitor  entry  TRACE  enables  (if  FLAG  is  true)  or  disables  (if  FLAG  is  false)  trace  output 
for  the  SUBJECT.  When  the  monitor  receives  an  entry  call  whose  CONSUMER  or  SERVER  parameter  is 
a  task  with  tracing  enabled,  then  the  monitor  will  display  the  call  and  its  parameters.  It  is  possible  to 
trace  ail  calls  to  the  monitor  by  using  entry  TRACE  with  parameters  ALL_TASKS  and  TRUE.  Normal 
tracing  is  restored  by  calling  TRACE  with  ALL_TASKS  and  FALSE. 


3.5  EVASIVE  ACTION 

A  deadness  error  is  imminent  whenever  the  OEADLK_FLAG  parameter  has  the  value  true  on 
completion  of  a  monitor  call.  Evasive  action  based  on  testing  this  parameter  value  may  be 
programmed  in  the  original  source  code  (see  Chapter  6).  The  two  entries  UNBLOCK  and  QUERY  are 
provided  to  assist  this. 

UNBLOCK  has  a  single  TASK_I0  parameter,  SUBJECT.  The  monitor  assumes  that  the  SUBJECT  task 
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will  not  proceed  with  the  originally  intended  rendezvous,  and  updates  its  picture  accordingly,  thus 
"unblocking"  the  task.  UNBLOCK  can  be  severely  misused.  It  should  only  be  called  from  the  task 
SUBJECT  when  the  OEAOLK.FLAG  parameter  has  been  returned  true,  and  SUBJECT  is  not  going  to 
proceed  with  the  tasking  statement  that  has  just  been  indicated  by  a  monitor  call. 

The  entry  QUERY  may  be  used  to  help  control  evasive  action  routines.  A  task  passes  the  monitor  the 
SUBJECT,  a  TASK.IO,  and  receives  information  about  how  that  task  is  blocked.  Specifically,  the  task 
and  entry  that  the  SUBJECT  is  calling  (If  any)  and  the  entries  that  the  SUBJECT  is  accepting  (if  any)  are 
returned.  This  entry  is  intended  to  allow  more  intelligent  evasive  action  by  giving  the  task  undertaking 
the  evasive  action  more  information  about  the  error. 
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4.  PREPROCESSOR 


This  section  describes  the  preprocessor  applied  to  the  Ada  text  of  a  program  P.  The  purpose  of  the 
preprocessor  is  to  introduce  communication  between  the  tasks  of  P  and  the  monitor  so  that  the 
monitor  is  informed  of  any  task  status  change  in  P.  The  resulting  monitored  program  is  denoted  by  P'. 

The  preprocessor  applies  a  sequence  of  textual  transformations..  Each  transformation  introduces 
new  declarations  or  statements.  The  transformations  currently  implemented  in  our  present  monitor 
extend  the  set  of  transformations  previousty  given  in  [Qerman,Heimbold.Luckham  82]  in  two  ways: 
(1)  the  set  of  deadness  errors  deteetwl  by  the  monitor  is  extended  to  include  errors  involving  the 
inability  to  terminate,  (2)  the  monitored  data  is  extended  to  inciude  data  necessary  to  give  an 
adequate  description  of  a  deadness  error  for  the  purpose  of  debugging  and  evasive  action.  Also  the 
original  presentation  lacked  disctission  of  many  important  implementation  details  upon  which  the 
correctness  of  an  actual  implementation  depends. 

The  transformations  can  be  broken  down  into  atomic  steps  describable  in  a  formalism  similar  to  the 
presentation  in  [German, Helmbold.Luckham  82].  However  formal  description  of  many  details  (e.g., 
transformations  for  composite  data  structures  containing  tasks,  and  for  parameter  expressions 
invoking  tasking]  is  very  complex.  So  here  our  descriptive  approach  is  informal.  We  describe  the 
preprocessor  as  a  sequence  of  four  passes.  First  the  monitor  declaration  and  body  is  placed  at  the 
beginning  of  the  declarative  part  of  the  main  program.  Following  this,  each  succeeding  pass  is  then 
assumed  to  take  its  input  from  the  output  of  the  preceding  pass.  Each  section  of  this  chapter 
describes  a  pass  (4.1  •  first  pass,  4.2  •  second  pass,  etc.).  We  will  use  Pic  to  designate  the  output  from 
the  l(th  pass,  thus  P2  is  the  output  from  the  transformations  described  in  Section  4.2. 

The  transformations  set  up  a  eorrespond9nc0  (Section  2.3)  between  P  and  P’  which  is  also  described 
informally  below. 

Notes: 

Only  the  original  rendezvous  attempts  between  tasks  in  P  are  monitored;  rendezvous  with  the  monitor 
itself  are  not  monitored.  All  identifiers  introduced  by  the  preprocessor,  s.g.  type  names  and  variables, 
are  asawmed  not  to  clash  with  the  identifiers  in  P. 


4.1  INTRODUCTION  OF  TASK  ID’S 

Passes  1  and  2  introduce  task  IDs  into  the  monitored  program.  Pass  1  introduces  data  structure  to 
store  IDs  and  communications  of  lOs;  pass  2  introduces  code  to  initialize  IDs.  The  resulting  program 
has  the  following  properties:  (1)  every  active  task  has  a  unique  ID.  (2)  a  calling  task  can  always 
access  the  called  task’s  ID,  (3)  a  task  can  access  its  own  ID,  (4)  within  every  scope  the  ID  of  the 
currently  executing  task  can  be  accessed,  and  (5)  whenever  an  entry  is  called  the  ID  of  the  caller  is 
passed  to  the  called  task. 

Notes: 

The  introduction  of  task  IDs  must  be  done  carefully  with  regard  to  the  Ada  semantics  of  task 
activation  to  avoid  errors  due  to  accessing  uninitialized  IDs. 

Pass  1  performs  the  following  six  transformations: 
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1.  Each  task  type  declaration,  t,  is  repiacad  by  a  new  task  type  called  t  TASK  followed  by  a 
record  type  with  the  originai  name.  t.  t.TASK  is  obtained  by  the  following  modifications  to 
the  original  declaration,  t:  A  new  entry.  SET_ID,  is  placed  in  the  task  type  declaration, 
and  a  new  variable,  MY_IO,  in  the  task  body;  an  accept  SET_I0  is  inserted  as  the  first 
statement  in  the  task  body.  The  new  record  type,  t,  has  two  components,  a  task  (called 
TASK_0B  J)  of  type  t.TASK  and  a  task  ID. 

2.  Each  task  declaration,  t,  in  Pis  replaced  by  a  task  type  declaration  t_TASK.  a  record  type, 
t_RECORO,  and  a  record  of  that  type  with  the  name,  t  The  task  type  t.TASK  is  obtained 
from  the  original  task  declaration  by  modMcationa  similar  to  Itioae  stated  in  stapi; 
t.RECORO  has  two  components  as  sbove. 

a  Entry  calls  to  any  task,  LE  say.  are  replaeed  by  entry  ealia  to  the  task  component  of  the 
new  record^  tTASKjQB J .  E. 

4.  A  new  formal  parameter  called  HY.IO  of  type  TASK.ID  is  added  to  every  subprogram 
specification. 

5.  A  new  formal  parameter  called  CALLER_I0  of  type  TASK.ID  is  added  to  ever/  entry 
specification. 

6.  All  calls  to  entries  and  subprograms  are  modified  appropriately  as  follows:  the  TASK.IO 
parameter  of  every  entry  and  subprogram  call  is  bound  to  the  value  of  MY.IO.  This  is 
either  the  value  of  the  local  MY.IO  variable  (if  the  call  is  in  a  task)  or  the  value  of  the 
formal  TASK.IO  parameter,  MY.IO  (if  die  call  is  in  a  subprogram). 

Notts: 

The  lO  of  the  main  program  always  has  the  value  0. 

As  a  result  of  step  1.  all  task  object  declarations  of  a  task  type  in  P  will  become  declarations  of  a 
record  type  in  Pi. 

As  a  result  of  steps  1  and  2  all  task  dsjects  occur  as  components  of  records  which  also  contain  a 
TASK. ID  component  We  will  call  these  tmsk  neords.  If  the  original  tasks  were  components  of  a  data 
structure,  the  new  task  records  take  their  place  in  the  structure  as  a  result  of  using  the  names  of  the 
original  tasks  as  names  for  the  task  record  types  (step  1)  or  task  records  (step  2). 

Wherever  a  task  was  visible  in  P,  now  both  the  task  and  its  ID  are  viaible  as  components  of  a  task 
record  with  the  same  name. 

The  SET.IO  entry  and  the  local  NY.IO  variable  are  used  to  "Inform”  a  task  of  its  own  10  when  it  is 
activated,  and  to  store  that  10. 

The  Ada  semantics  do  not  specify  the  order  of  task  activation.  Therefore  at  steps  i  and  2  accept 
SET.IO  is  inserted  as  the  Rrst  statement  of  every  task  body;  in  pass  2  task  10  components  of  all  task 
records  are  initialized  before  any  task  is  informed  of  its  10  by  a  SET.ID  entry  call.  This  "holds  up” 
every  task  until  all  10  components  are  initialized,  thus  avoiding  the  possibility  that  tasks  in  P'  might 
attempt  to  access  task  10  components  that  are  uninitialized. 

The  purpose  of  steps  4  •  6  is  to  ensure  that  the  actual  value  of  the  CALLER.ID  parameter  of  any  entry 
call  is  the  10  of  the  task  issuing  that  call.  This  in  turn  requires  that  a  subprogram  must  be  able  to 
access  the  10  of  the  task  that  called  it  so  that  if  it  issues  an  entry  call  it  can  pass  this  10  to  the  called 
task.  (Note  that  a  subprogram  can  be  visible  to,  and  thus  called  by,  more  than  one  task.)  Hence  the 
TASK.IO  parameter  must  be  added  to  both  subprograms  and  entries. 

Correspondence:  After  pass  1,  eomspondtnets  between  text  of  P  and  new  or  modified  text  of  P1 
is  as  follows  (text  in  P  that  is  not  affected  by  the  transformations  corresponds  to  the  same  text  in  Pi ): 
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A  task  objact  t  in  P  cornsponds  to  the  task  object  component  of  the  record  with  the  same  name,  t,  in 
P1:  i.e..  t  corresponds  to  t.TASK_0BJ.  A  task  type  t  in  P  corresponds  to  a  task  type  in  P1  obtained  by 
modifying  the  declaration  of  t  at  step  i  above  (called  t_TASK).  The  old  and  new  subprogram  and 
entry  declarations  and  entry  calls  correspond.  The  new  variables  MY_I0.  entries  SET.IO,  calls  to 
SET.IO.'Snd  new  accept  SET^IO  statements  have  no  correspondence  in  P. 


4.1.1  IXAMPmOP  PASS  1  TRANSPORMATMNS 

t.  A  task  type  deeleretion  Is  trsnstormed  into  e  tssk  type  toUowed  by  s  record  type: 
Note:  T1  corresponds  to  T1.TASK. 

OmOMALTBXT.Ps 

task  type  Tl  Is 
entry  El: 

entry  E2  (I  :  in  INTEGER:  .  .  .): 
end  Tl: 

task  body  Tl  is 
•  «  • 
begin 

end  Tl:  . 


transformed  text.  PI: 

task  type  Tl.TASK  is 

entry  SET_ID  (M  :  In  TASK.ID):  entry  El  (CALLER.ID  :  In  TASK.ID): 
entry  E2  (CALLER.IO  :  In  TASX.ID:  I  :in  INTEGER:  .  .  .): 
end  Tl.TASK: 
task  body  Tl.TASK  is 
MY_I0  :  TASK.ID: 

•  •  « 
begin 

accept  SET.IO  (N  :  in  TASK.ID)  do 
MV.ID  :■  N; 

end  TiItaSK; 

type  Tl  is 
record 

TASK.OBJ  :  Tl.TASK: 

10  :  TASK.ID: 

end  record : 

2.  All  tssk  object  decisrstlons  become  tssk  record  object  declsrstlons: 

Note;  A.TASK  corresponds  to  A.TASK .  TASK.OB  J. 

ORIGINAL  TEXT,  P: 


A.TASK  :  Tl: 


TRANSraRMIO  TIXT.  PI: 

A.TASK  :  Tl: 

3.  Declarations  of  a  single  task  are  transformed  into  a  task  type  and  record  type  declaration,  followed 
by  a  record  declaration: 

Note:^^  corresponds  to  Tl .  TASK.OB 3.  OfHOINALTKXT,  P: 

task  Tl  is 
sntry  El: 

sntry  E2  (N  :  in  INTEGER:  .  .  .): 
and  Tl: 

task  body  Tl  is 
and  Tl:  ‘ 


TPANSPORMEO  TEXT,  PI : 

task  typa  Tl.TASK  is 

antry  SET.IO  (M  :  In  TASK_ID); 

sntry  El  (CALLER  10  :  in  TASK.ID); 

sntry  E2  (CALLER_I0  :  m  TASK_ID; 

N  :in  INTEGER:  .  .  .): 

snd  T1_TASK; 

task  body  Tl.TASK  is 
MY.IO  :  TASK.IO; 

•  «  « 
bsgin 

aeeapt  SET.IO  (N  :  .  .  .)  do 
HY.IO  :•  N; 
snd  SET.IO: 

snd  TiItaSX: 

typa  T1_REC0R0  is 
rooord 

TASK.0BJ  :  Tl.TASK: 

10  ;  TASK.ID: 

snd  raeord: 

Tl  :  T1_REC0R0: 


4.  Pass  1  transformations  modify  subprogram  and  entry  declarations  and  calls: 


OmOINALTEXT,  P: 

proesdurs  PROCl  is 
snd  PROci; 


function  Fl  (I  :  in  INTEGER) 
rstum  SOME.TYPE  is 
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•fid 

PROCl; 

1C:-  FI  (J); 

T1.E2  (N): 

TNANSPOmilOTIXr,  ri: 

proe«dur«  PROCl  (Nr.10  :  in  TASK.IO)  Is 
•nd  PROci: 

function  Ft  (NY.ID  :  in  TASK.IO;  I  :  toi  INTEGER) 
ictum  SOME.TYPE  la 

•nd  FU* 

PROCl  (MY.ID); 

K  :•  FI  (MY_I0.  J); 

T1.TASK_0BJ.E2  (MY_I0.  M): 


4.2  INITIAUZATION  OF  TASK  iO*S 

Pass  2  aceapts  as  input  tha  result  of  Pass  i  and  inserts  statements  to  initialize  TASX.ID  components 
and  variables.  When  a  task  record  is  declared,  the  declaring  scope  must  call  the  monitor  to  obtain  a 
new  10,  initialize  the  10  field  of  the  task  record,  and  inform  the  task  of  its  10.  If  several  tasks  are 
declared  in  the  same  declarative  part  then  all  of  the  10  record  components  must  be  initialized  before 
letting  any  task  proceed,  otherwise  one  of  the  tasks  could  access  an  iO  component  before  it  has  been 
initialized. 

The  Pass  2  tranaformationa  for  initializing  the  IDs  of  statically  declared  tasks  in  each  declarative  part 

are; 

1. For  each  task  record  declaration  a  call  to  NONITOR.NEWTASK  is  inserted;  the  string 
parameter  of  this  call  is  bound  to  tfw  task  record  name  and  the  TASK.IO  parameter  is  the 
taak  record  10  component  If  the  declaration  is  in  the  declarative  part  of  a  subprogram  or 
block  the  call  is  placed  in  the  first  statement  position  of  that  subprogram  body  or  block;  if 
the  declaration  is  in  the  declarative  part  of  a  taak  body,  the  call  is  placed  immediately 
following  the  accept  SET.IO  statement  of  the  task  body. 

2.  Immedately  following  ail  the  calls  to  MONITOR. NEWTASK  inserted  at  step  i,  calls  to  the 
SET.IO  entry  of  the  taak  component  of  each  taak  record  are  inserted;  the  TASK.IO 
parameter  of  each  call  is  bound  to  the  lO  component  of  the  same  task  record.  ~ 

If  ta^  are  declared  as  part  of  a  complex  structure  (built  out  of  arrays,  records,  and  access  types) 
then  Pass  2  uses  iterative  techniques  to  construct  the  initialization  code  for  objects  of  that  complex 
type.  E.g..  task  IDs  oceuring  as  components  of  arrays  are  initialized  by  for  loops  iterated  over  the 
array  index  type.  Details  of  these  techniques  are  omitted. 
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Notts:  ' 

Calls  insertsd  by  step  1  will  inform  the  monitor  of  the  identifier  in  the  source  text  to  be  associated  with 
each  task  (for  tracing  and  debugging)  and  will  initialize  all  task  record  lO  components.  The  monitor 
can  then  associate  its  own  ID  for  a  task  with  a  name  for  the  task  in  the  source  text.  If  a  task  occurs  as 
a  value  in  a  data  structure,  the  name  of  the  global  data  structure  is  used,  so  in  general  many  IDs  may 
be  associated  with  a  source  text  name.  Aa  a  result  of  calls  inserted  at  step  2,  all  tasks  now  "know" 
their  ID’S,  and  have  been  "held  up"  until  sil  ID  components  are  initialized. 

Cerrespondenee:  Text  to  biMaHze  task  id’s  added  by  Pass  2,  steps  1  and  2  does  not  correspond  to 
any  text  in  P. 


4.a.i  axAMKii  oa  pass  aTtuNaaomiATioM 

PI  OaCLASATtVaPASTi 

T1  :  SOME_TASK_TYPE ; 

TASK_ARRAY  ;  array  (1..S)  of  SOME_TASK_TYPE ; 

type  TWO_TASkS_TYPE  is 
record 

FIRST  :  SOME.TASK.TYPE; 

SECOMO  ;  SOME.TASK.TYPE; 

N  :  INTEGER;  . 

end  record : 

TWO.TASKS  :  TWO.TASKS.TYPE ; 


PI  ^MMCOIATSUY  POU.OYnMQ  StQW! 

—  Tsxt  to  initialize  all  task  ID  components 

MONITOR. MEWTASK  ‘("Tl",  Tl.ID); 
for  I  in  1 . .  5  loop 

MONITOR. MEWTASK  ("TASKJ^ItRAY".TASK_ARRAY  (I). ID); 
end  loop : 

MONITOR.NEWTASK  ("TWO.TASKS. FIRST",  TWO_TASKS.FIRST. ID) ; 

MONITOR. NEWTASK  ( "TWO.TASKS. SECOND” ,  TWO_TASKS.SECONO.ID) ; 

--  Text  to  inform  all  tasks  of  th^r  ID 's 

T1,TASK_08J.SET_I0  (Tl.ID); 
for  I  in  (1..8)  loop 

TASK_ARRAY  (I).TASK_08J.SET_ID  (TASK_ARRAY  (I). ID); 
end  loop ; 

TW0_TASKS .FIRST. TASK_0B J . SET_I0  ( TW0_TASKS . F I RST . ID ) ; 

TWO.TASKS . SECOND . TASK.OB J . SET.ID  ( TWO.TASKS . SECOND . ID ) ; 


Note  on  Example:  Due  to  Pass  1,  SOME_TASK_TYPE  is  now  a  task  record  type. 

The  situation  in  which  a  new  task  is  created  and  activated  by  an  allocator  requires  special  handling  in 
Pass  2.  If  P  contains  an  access  type  accessing  a  type,  T,  with  task  type  components,  then  P1  will 
contain  an  access  type  accessing  T  which  now  has  task  record  components.  Allocation  of  an  object 
of  type  T  must  not  be  permitted  to  make  an  ID  component  visible  before  it  is  initiaiizsd.  Our  approach 
is  to  "hide”  such  allocators  in  function  calls. 
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Pan  2  conttina  a  third  atep: 

3.  Whanevar  an  accasa  typa  which  dasignates  a  type  containing  task  componants  is  deciarad,  Pass  2 
insarts  a  naw  function  declaration  to  ba  associated  with  the  access  type.  This  function  will  taka  as 
paramater  a  value  of  the  accasa  type  and  return  the  same  value.  It  initializes  ail  task  IDs  in  the 
object  dasignatad  by  its  parameter.  Wherever  an  allocator  is  called  in  P1  to  create  a  new  object 
containing  task  components.  Pass  2  will  substituta  a  call  to  this  new  function  in  P2  with  the  value  of 
the  allocator  call  aa  its  actual  paramatar. 

Corraapondance:  The  naw  (unetiona  and  calls  to  tham  have  no  corraspondanca  in  P1.  The 

alloeator  calls  in  Pi  eomspond  to  the  alloeator  can  paramatera  of  the  naw  function  calls  in  P2. 

Sxampfm 


ai: 


type  TV10_TASKS_TYPE  is 
record 

FIRST  :  SOME_TASK_TYPE; 
SECOMO  :  SOME_TASIC_TYPE: 
N  :  INTEGER: 

and  record : 

type  TWO_TASKS_REF  is 

accasa  TVIO.TASKS.TYPE ; 

TVIO,TASKS_PTR  :  TWO_TASKS_REF ; 


TWO.TASKS.PTR  naw  TWO.TASKS; 


PS; 


type  TOO.TASKS.TYPE  is 
record 

FIRST  :  SOME.TASK^TYPE; 

SECOND  :  SONE^TASK^TYPE ; 

N  :  INTEGER: 

and  record : 

typa  TWO_TASKS_REF  is 

accasa  TVIO_TASKS_TYPE: 

function  NEW  TWO  TASKS  (TEMP  :  in  TWO.TASKS.REF)  return 
TWO_TASKS_REF  is 

—  InitiallZB  TASKJDs  in  TEMP 

begin 

MONITOR.NEWTASK  (.  .  .): 

MONITOR. NEWT ASK  (.  .  .): 

TWO.TASKS.REF.FIRST.SET_ID  (.  .  .): 

TWO_T ASKS. REF. SECOND. SET.IO  (.  .  .); 
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r»tum  TEMP; 

•nd  IIEW_TW0_TASKS: 

TWO.TASKS.PTR  :  TWO.TASKS.REF; 


TWO.TASKS.PTR  :•  MEW.TW.TASKS  (n*w  TWO.TASKS); 

AtolM  on  Example: 

Compondnla  FIRST  and  SECOND  wnra  originally  taak  typaa  in  P.  and  hava  bacoma  taak  racord  typaa 
in  PI  aa  a  laautt  of  Paaa  1.  Whan  TlfO_TASKS_PTR  can  ba  rafarancad  in  P2,  all  of  tha  iO’s  in  tha 
daalgnatad  obiact  will  hawa  baan  inibalizad. 


4.3  MONITORING  OF  DEPENDENT  TASKS 

The  monitor  cannot  detect  some  dead  states  without  dependency  information.  For  example,  a  task 
moves  from  status  BLOCK_WAIT  to  status  RUNNING  when  all  of  its  dependents  declared  in  the  block 
have  terminated.  Consequently,  a  task  may  be  dead  as  a  result  of  a  deadness  among  its  dependents 
which  prevents  them  from  terminating. 

In  order  to  deal  with  such  situations,  the  preprocessor  adds  a  variable  designating  a  list  of 
(dependent)  task  ids  to  each  block,  i.e.,  each  block  in  P'  that  corresponds  to  a  block  in  P  contains  a 
list  of  all  tasks  dependent  on  that  block.  The  prsprocessor  also  adds  calls  to  the  monitor  entry. 
AOO_0!:?£NCENTS,  with  this  list  as  a  parameter,  v^henever  a  new  dependent  task  is  activated.  At 
runtime  this  list  is  passed  to  the  monitor  by  the  executing  task  when  a  new  dependent  task  is 
activated,  or  when  the  executing  task  has  reached  the  end  of  that  block.  Thus,  in  this  present  monitor 
design,  updating  of  dependents  lists  and  checking  for  termination  is  done  by  the  monitor  itself. 

Pass  3  declares  a  new  local  variable,  0EPEN0ENT_I0S,  at  the  beginning  of  every  declarative  part  of 
P2,  except  those  in  the  new  subprograms  introduced  in  Pass  2.  This  variable  designates  a  linked  list 
of  all  tasks  directly  dependent  on  the  block  where  it  is  declared.  An  additional  variable. 
ALL_0EPEN0ENTS,  is  added  to  the  outermost  declarative  portion  of  every  task  body  and  the  main 
program.  These  lists  are  modified  only  by  calls  to  the  monitor's  A0D_DEPEN0ENT  entry.  After  every 
NEWT ASK  call,  Pass  3  inserts  an  A00_DEPEN0ENT  call  to  the  monitor  with  parameters:  the  10  of  the 
task  executing  the  block,  the  10  of  the  dependent  task,  the  DEPENDENT_IDS  variable,  and  the 
ALL.OEPENOENTS  variable. 

Pass  3  of  the  preprocessor 

1.  Adds  the  declaration,  "DEPENOENT.IDS  :  MONITOR_DATA_PACKAGE .  ID_PTR"  at  the 
beginning  of  each  declarative  part  of  P2  except  for  the  new  subprograms  whose 
declarations  were  inserted  by  pass  2. 

2.  Adds  the  declaration  -ALL_OEPENDENTS  :  M0NIT0R_0ATA_PACKAGE .  ID_PTR"  at 
the  beginning  of  the  outermost  declarative  part  of  each  task  body. 

3.  Inserts  the  call  MONITOR. ADO _ DEPENDENT  after  each  call  to  the  monitor  entry, 

MEW_TASK.  The  parameters  are  FATHER  ■>  MY__ID.  .SON  ■>  out  parameter  of 
preceding  NEWTASK  call,  LIST l  •>OEPENOENT.IDS,  LIST2  >>  ALL.OEPDENOENTS. 


Notts:  Tasks  craatad  by  an  allocator  dapend  on  tha  block  whara  tha  accass  type  was  dactared,  so 
thsir  ID’S  must  bo  addad  to  tha  OEPENOENT__IOS  list  corrosponding  to  that  block.  In  P2  these 
allocator  calls  are  replaced  by  calls  to  a  new  function  associated  with  tha  access  type.  This  function  is 
declared  immediately  following  the  access  type  by  Pass  2.  It  contains  the  appropriate  NEW_TASIC 
calis.  Since  pass  3  does  not  insert  a  declaration  of  a  local  OEPENDENT.IDS,  ...  in  these  function 
bodies,  the  immediately  global  DEPENDENT  .^IDS  variable  is  visibie  within  these  function  bodies. 
These  will  be  the  DEPENDENT  ^IDS  variables  associated  with  the  declarative  parts  containing  the 
access  type  declaratlona.  Therefore  the  Pass  3  monitor  calls  to  ADD_DE PENDENT  placed  in  the 
function  win  have  as  parameter  the  DEPENDENT  ^IDS  variable  for  the  block  in  which  the  access  type 
is  declared. 

If  a  sefeet  statement  say,  in  taak  Tl.  has  a  terminate  altsrnative.  then  the  ID’s  of  an  tasks  directly 
dependent  on  Tl,  or  one  of  its  inner  blocks,  must  be  psssed  to  the  monitor.  The  variable 
ALI^.OEPENOENTS  designalae  a  list  of  exactly  these  ID'S. 

Correspondence:  The  text  added  to  P3  in  Pass  3does  not  correspond  to  text  in  P2. 


4.4  RENDEZVOUS  MONITORING 

Pass  4  inserts  calls  to  the  monitor  entries  CALLING,  ACCEPTING.  SELECTING,  START_RErJDE2V0US, 
END_RENDEZVOUS,  END.BLOCK,  and  END.TASK.  These  calls  inform  the  monitor  of  direct  and  indirect 
status  changes,  and  associated  information  arising  from  rendezvous  attempts. 

The  transformation  uses  strings  derived  from  the  source  text  identifiers  as  names  of  task  entries. 
These  names  are  used  to  notify  the  monitor  which  entry  of  a  task  is  being  called  by  another  task  and 
are  crucial  in  the  monitor's  internal  representation  of  rendezvous  statuses.  These  entry  name  strings 
must  name  exactly  one  entry  in  any  given  task:  no  entry  can  be  represented  by  two  different  strings, 
and  no  string  can  represent  two  different  entries  of  the  same  task.  A  string  could  represent  several 
entries,  as  long  as  they  are  all  in  different  tasks.  An  entry  family  requires  a  different  string  for  each 
member  of  the  family.  Rnally,  the  transformation  introduces  arrays  for  storing  and  accessing  the 
names  associated  with  entry  families;  details  of  these  entry  family  name  arrays  are  omitted. 


4.4.1  THE  CALUNO  ENTRY 

Calls  to  this  entry  are  inserted  in  a  task  P  immediately  before  an  unconditional,  untimed  entry  call. 
When  a  call  to  CALLING  is  executed,  the  monitor  will  change  the  status  of  the  task  to  Calling.  As  soon 
as  this  monitor  call  finishes  and  the  next  statement  is  executed,  the  task's  actual  status  will  be  Calling. 
Timed  and  conditional  entry  calls  are  not  monitored  because  they  do  not  result  in  the  task  changing 
status  (until  the  call  has  actually  been  accepted).  The  CONSUMER  parameter  is  the  ID  of  the  task 
making  the  call,  i.e.,  the  value  of  MY_ID.  The  SERVER  parameter  is  the  ID  component  of  the  called 
task's  task  record.  The  ENTRY_NAME  parameter  is  the  string  created  by  the  preprocessor  naming  the 
called  entry.  The  DEADLK.FLAG  parameter  indicates  whether  evasive  action  should  be  taken  to  avoid 
a  blocked  state. 

Notts: 


Exsmpits: 


T1.TASK_0BJ.E1  (MY_I0): 
Tl.TASKOBJ.ENTRY.FAHILY  (EXP)  (MY  ID); 
T1.TASK0BJ.E2  (MY_ID.  PARAMETER); 


P4: 


MONITOR. CALLING  (MY.IO.  Tl.IO.  *E1”.  OEAOLK_FLAG) : 

T1.TASK_0BJ.E1  (MY_IO): 

MONITOR. CALLING  (MY.I&k  Tl.IO.  ENTRY.FAMILY^STR  (EXP).  OEAOLK  FLAG); 
T1 .TASKOBJ . ENTRY_FAMILY( EXP) (MY_ID) ; 

MONITOR. CALLING  (MY.IO. Tl. 10. ”E2”;  DEAOLK_FL): 

Tl. TASKOBJ. E2  (MY.IO.  PARAMETER): 


4.4.2  THE  ACCEPTING  ENTRY 

Pass  4  inserts  a  call  to  ACCEPTING  immediately  before  each  ’’simple'*  accept  statement  that  is  not  a 
select  alternative  (preprocessing  of  select  alternatives  is  described  in  4.4.3).  The  parameters  are: 
MY.IO  (server  name),  the  preprocessor  string  naming  the  entry  being  accepted,  and  DEAOLK.FLAG. 

Example: 


P3: 


accept  El  (CALLER.IO)  do 


P4: 


MONITOR. ACCEPTING  (MY.ID,  "El",  OEAOLK.FLAG) ; 
accept  El  (CALLER.IO)  do 


4.4.3  THE  SELECTING  ENTRY 

Before  executing  a  select  statement  a  (server)  task  must  inform  the  monitor  of  those  entries  that  can 
be  accepted  by  that  select  statement.  It  must  therefore  evaluate  the  guards  of  the  select  alternatives, 
including  any  delay  or  terminate  alternatives.  This  evaluation  must  be  done  once.  The  resulting 
values  are  used  both  to  give  the  monitor  the  information  associated  with  the  new  Accepting  status  (or 
Select.terminate  status)  and  to  execute  the  select  statement  afterwards.  Pass  4  inserts  declarations 
of  new  variables  to  hold  the  values  of  the  guards,  and  text  to  evaluate  the  select  guards  and  construct 
the  status  information  for  the  monitor. 

Pass  4  executes  the  following  text  transformations  for  each  select  statement  in  P3: 

1 .  The  select  statement  is  enclosed  in  the  body  of  a  new  block  statement. 


2.  Boolean  variables  TEMPI,  TEMPZ,  . 


.  .  are  declared  locally  in  the  new  block,  one  for 


33 


each  select  alternative,  and  initialized  to  the  guard  expression  of  that  alternative,  or  to 
TRUE  if  there  is  no  guard. 

3.  Boolean  variables  TEMP_D£LAY  and  TEMP_TERMIMATE  are  declared  locally  after  the 
previous  variables.  TEMP^OELAY  is  initialized  to  TRUE  if  there  is  an  else  part,  to  the 
disjunction  of  the  TEMP  variables  corresponding  to  delay  alternatives,  or  to  FALSE  if  there 
is  no  else  part  or  delay  altematives.  TEMP_TERMINATE  is  initialized  to  the  TEMP  variable 
corresponding  to  the  terminate  alternative  if  there  is  one  and  to  FALSE  otherwise. 

4.  A  variable  ENTRY.LIST  of  type  ENTRY. PTR  is  declared  locally  and  initialized  to  null. 

5.  Ada  text  to  construct  the  list  of  entry  names  corresponding  to  open  accept  altematives  is 
inserted  at  the  beginning  of  the  local  block  body  (i.e..  before  the  select  statement).  This 
text  is  instantiated  from  a  single  text  template  and  performs  a  computation  as  follows:  if 
TEMP_OELAY  is  TRUE  it  does  nothing;  otherwise  it  builds  a  list  of  entry  name  strings 
corresponding  to  the  open  accept  alternatives  and  then  calls  the  monitor  entry, 

SELECTING,  with  parameters:  MY _ ID.  ENTRY _ LIST,  TEMP _ TERMINATE, 

ALL.OEPENDENTS, OEADLK_FLAG. 

6.  The  boolean  conditions  in  the  select  alternatives  are  replaced  by  the  corresponding  TEMP 
variables. 

Correspondence:  The  select  statement  in  P4  corresponds  to  the  original  select  statement  in  P3. 

The  new  local  block,  declarations,  and  new  text  in  P4  has  no  correspondence  in  P3,  except  that  calls 

to  functions  in  the  new  text  corresponds  to  the  original  calls  in  guards  in  P3. 

Notes: 

1.  If  TEMP.OELAY  is  TRUE  the  server  task  cannot  enter  a  blocked  state  but  will  remain  in 
status  Punning. 

2.  TEMP_TERMINATE  is  declared  even  if  there  is  no  terminate  alternative  so  that  the 
preprocessor  can  use  asingle  text  template  for  computing  the  list  of  open  entries. 

3.  TEMP_OELAY  and  TEMP_TERMINATE  cannot  both  be  true  due  to  Ada  rules  for  select 
statements. 

4.  Construction  of  the  list  of  entries  proceeds  as  follows:  ENTRY.LIST  is  initialized  to  null; 
then  for  each  accept  alternative  with  a  true  guard  condition  a  new  MON.ENT.REC  record 
containing  the  string  representing  the  entry  is  allocated.  If  the  entry  is  part  of  an  entry 
family,  its  index  expression  is  evaluated  at  this  point  (to  correspond  with  the  order  of 
evaluation  in  the  Ada  semantics).  This  record  is  inserted  into  the  ii£*  designated  by 
ENTRY.LIST. 

Examples: 


P3: 


select 

accept  El  (CALLER.ID  :  in  TASK.IO)  do 

end  El; 
or 

accept  E2  (CALLER.IO  :  in  TASK.ID); 
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I  :  in  INTEGER)  do 

•nd  E2: 

•nd  soloet : 

soloct : 

whon  FLA61  ■> 

aeeopt  El  (CALLER.IO  :  in  TASK.ID)  do 

•nd  El: 
or 

wh«n  F  (X)  •>  d«lay  10; 
and  aaloct; 

p*t 

daelar* 

TEMPI  :  BOOLEAN  :«  TRUE: 

TEMP2  :  BOOLEAN  :•  TRUE: 

TEMP.OELAY  :  BOOLEAN  ;•  FALSE; 

TEMP_TERMINATE  :  BOOLEAN  :«  FALSE; 

ENTRY_LIST  :  ENTRY_PTR  •, 
begin 

if  not  TEMP_OELAY  then 
ENTRY.LIST  null: 

If  TEMPI  then 

EMTRY.LIST  :■  new  ENTRY_REC’ ( NAME  ■>  "El".  NEXT  «>  ENTRY_LIST) 
end  if ; 

If  TEMP2  then 

ENTRY.LIST  :•  new  ENTRY.REC* (NAME  »>  "Ea".  NEXT  *>  ENTRY.LIST) 

end  if ; 

MONITOR. SELECTING  (MY.IO.  ENTRY.LIST.  TEMP.TERMINATE . 

ALL.DEPENDENTS ,  OEAOLK.FLAG ) ; 

end  if; 
select 

accept  El  (CALLER.IO  :  in  TASK.ID)  do 

end  El; 
or 

accept  E2  (CALLER.IO  :  in  TASK.ID; 

I  :  in  INTEGER)  do 

end  E2; 

•nd  select ; 

•nd; 


TEMPI 

:  BOOLEAN 

;  m 

FLAGl; 

TEMP2 

:  BOOLEAN 

;  m 

F  (X); 

TEMP.DELAY 

:  BOOLEAN 

1  9 

TEMP2; 

TEMP.TERMINATE 

:  BOOLEAN 

1  9 

FALSE; 

begin 

if  not  TEMP.DELAY 

then 

ENTRY.LIST  : 

*  null; 

if  TEMPI  then 

ENTRY  LIST  :•  new  ENTRY_REC( NAME  «>  "El". 

NEXT  •>  ENTRY.LIST); 


end  if; 
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/ 


if  TEMP2  then 

EMTRY^LIST  :•  new  EMTRY_REC(HAME  ■>  "EZ*. 

NEXT  ->  ENTRY_LIST); 

end  if; 

MONITOR. SELECTIM6(MY_ID.  ENTRY_LIST.  TEMP_TERMINATE . 

ALL.DEPENDENTS) ; 

end  if; 

eeiect 

when  TEMPI  >> 

eceept  El  (CALLER_ID)  do 

end  El: 
or 

when  TENP2  ■>  delay  10: 
end  select; 
end  If : 

end; 


Often  text  inserted  by  the  preprocessor  pass  4  can  be  om  itted.  in  the  first  example  above,  none  of 
the  TEMP  variables  for  accept  alternatives,  nor  the  corresponding  conditional  tests  on  them,  are 
needed.  The  preprocessor  does  in  fact  make  some  optimizations  on  the  use  of  the  TEMP  variables. 


4.4.4  ENTRY  START  RENDEZVOUS 

Pass  4  inserts  a  call  to  this  monitor  entry  at  the  beginning  of  every  accept  body,  even  those  inside  of 
select  statements.  The  parameters  of  the  call  are:  CONSUMER  ■>  CALLER_ID  (a  parameter  of  the 
entry  call).  SERVER  «>  MY_I0,  ENTRY_NAME  »>  the  name.string  associated  with  the  entry  being 
accepted. 

Correspondence:  This  entry  call  has  no  corresponding  code  in  P. 


4.4.S  ENTRY  ENO.RENOEZVOUS 

A  call  to  this  entry  is  placed  at  the  end  of  every  accept  body.  The  parameters  of  this  call  are: 
CALLER.IO,  MY^IO,  and  the  string  associated  with  the  entry  accepted.  This  entry  call  does  not 
correspond  to  any  code  in  P3. 

Examples: 


accept  El  (CALLER.IO  :  in  TASK.ID): 

accept  E2  (CALLER.IO  :  in  TASK;_ID:  I  :  in  INTEGER;  .  .  . )  do 


P4: 


end  E2 
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aee«pt  El  (CALLER.ID  :  in  TASK.ID)  do 

MONITOR. START_RENDEZVOUS  (MY_ID.  CALLER_ID,  "El"); 
MONITOR. ENO.RENDEZVOUS  (MY_ID.  CALLER.ID,  "El"): 

•nd  El: 

aeeopt  E2  (CALLER.IO  :  in  TASK.ID.)  (I  :  in  INTEGER;  .  .  . )  do 
MONITOR. START_RENOEZVOUS  (MY_ID,  CALLER_ID.  "E2"); 

MONITOR. ENO.RENOEZVOUS  (MY.IO,  CALLER.IO,  "E2"): 
and  E2 : 


4.4.6  BITRY  BNOJASK 

A  call  to  this  antry  is  inasrtad  at  tha  and  of  avoiy  task  body.  Tha  paramatars  ara  MY.IO  (tha  iO  of  tha 
task  that  ia  eompriating).  ALL_OEPENOENTS  (tha  ID’S  of  alt  tasks  dapandant  on  tha  completing  task), 
and  OEAOLK.FLAG.  Tha  value  returned  for  DEAOLK.FLAG  will  indicate  whether  or  not  the  task  will 
cause  a  blocked  state  by  completing.  This  entry  call  does  not  correspond  to  any  code  in  P. 


4.4.7  ENTRY  ENO.BLOCK 

A  call  to  this  entry  is  inserted  at  the  end  of  each  inner  block  (or  subprogram)  which  has  a  declarative 
part.  The  parameters  are  the  same  as  for  ENO.TASK,  except  that  the  local  DEPENOENT_IDS  variable 
takes  the  place  of  ALL.DEPEMOENTS.  Again,  this  entry  call  does  not  correspond  to  any  code  in  P3. 


4.5  FUNCTION  CAULS  IN  TASKING  STATEMENTS 

The  above  transformations  are  inadequate  when  parameters  of  tasking  statements  contain  function 
calls  since  evaluation  of  these  parameters  might  also  involve  tasking. 


Example: 

P; 


function  Fl  (ARG:  in  INTEGER) 
return  INTEGER  is 
T3:  SOME_TASK_TYPE; 

begin 

end  n  - 

T1.E2  (Fl  (X)); 


P4: 


function  Fl  (MY_I0;  In  TASK.ID;  ARG  :  in  INTEGER) 
return  INTEGER  is 
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T3:  SOME.TASK.TYPE; 

DEPEMDEMT.IDS  :  ID.PTR; 

b«gin 

MONITOR. MEW^TASK  (.  .  .); 

MONITOR.AOO.OEPENOENT  (.  .  .); 

MONITOR. SET.ID  (.  .  .); 

MONITOR . ENO.BLOCK  (MY.XO . *  OEPENDENT.IDS .  OEAOLK_FLAG ) ; 
•nd  FI: 


MONITOR. CALLING  (MY.IO.  Tl.ID.  ‘EE*); 

.  —  A 

Ti.TASK.0BJ.E2  (MY.IO.  FI  (MY.ID.  X)): 

At  point  A  in  th«  abovo  exampio,*  T1  ia  in  status  Calling  in  tha  monitor's  pictura.  Howavar,  whan  tha 
cail  to  FI  is  axecuted,  T1  could  ba  put  into  status  Block.Wait  waiting  for  tasks  depandant  on  Pi  to 
terminate.  Currently,  this  will  confuse  tiie  monitor  and  may  lead  it  to  falsely  detect  a  global  blocking 
situation,  or  not  detect  an  actual  one.  The  preprocessor  therefore  moves  all  function  calls  out  of  the 
tasking  statements.  This  requires  additional  temporary  variables  to  hold  the  values  of  parameter 
expressions  and  intermediate  values. 

ex»mpl9S: 


P4: 


MONITOR. CALLING  (MY_ID.  Tl.IO,  "E2"); 
n.TASK_08J.C2  (MY_IO.  FI  (MY_IO.  X)); 


PS: 


TEMPI  :•  FI  (MY_ID,  X); 

MONITOR. CALLING  (MY_ID.  Tl.IO,  "EZ*); 
T1.TASK_0BJ.E2  (MY_ID.  TEMPI); 


5.  CORRECTNESS  OF  DEADNESS  DETECTION 

In  this  chaptsr  we  outline  an  approach  to  proving  the  correctness  of  our  runtime  monitoring  system. 
A  formal  treatment  of  correctness  with  detailed  proofs  is  beyond  the  scope  of  this  paper.  We  attempt 
here  to  indicate  what  needs  to  be  proved  and  informai  reasoning  which  can  be  formalized. 

Correctness  is  taken  to  mean:  (I)  for  any  potential  deadness  error  of  the  original  program  P  there  is 
an  equivaient  potential  deadneaa  error  in  the  monitored  program  P*;  00  in  any  computation  of  P*.  if  the 
monitor  detects  a  deadnesa  error,  K  will  do  so  before  that  error  occurs  and  that  error  will  occur  if  the 
computation  continues  normaily.  WO  certain  kinds  of  deadneaa  errors,  inchidfng  global  blocking  and 
dreular  deadlock  will  always  be  detected, 

Afoie* 

67  means  that  ttM  monitor  does  not  interfere  with  the  aet  of  potential  deadneaa  errors  of  the  monitored 
program.  0l>  does  not  imply  that  the  monitor  will  detect  every  deadneaa  error,  as  defined  in  Section 
2.2,  but  that  any  error  it  can  detect  in  its  picture  will  be  a  future  state  of  P*.  OiO  is  a  completeness 
result. 


5.1  NON  INTERFERENCE 

The  preprocessing  (Chapter  4)  and  addition  of  the  monitor  sets  up  a  textual  correspondence  between 
P  and  P*.  Declarations  of  subprograms  and  entries  in  P  correspond  to  subprograms  and  entries  with 
the  same  name  in  P';  declarations  of  task  types  correspond  to  task  types  in  P';  task  objects  of  P 
corresoond  to  task  components  of  task  record  objects  in  P’;  statements  that  are  untouched  by  the 
transformation  correspond;  calls  to  subprograms  and  entries  in  P  correspond  to  calls  to  subprograms 
and  entries  with  the  same  names  in  P';  finally  the  corresponding  is  consistent  (Section  2.3),  in 
particular,  the  block  structure  of  P  is  preserved  in  P’.  The  monitor,  calls  to  the  monitor,  and  additional 
object  declarations  and  statements  inserted  prior  to  monitor  calls  do  not  correspond  to  text  in  P. 

The  following  discussion  is  based  on  this  correspondence  between  P  and  P'. 

Claim  1 .  For  every  execution  of  P  there  is  a  corresponding  execution  of  P’  and  conversely. 

Nores.*  this  depends  on  the  assumptions  (0  that  ail  tasks  of  P  have  the  same  priority,  00  on 
properties  of  the  correspondence  whereby  corresponding  statements  invoke  the 
same  status  change  (if  any)  on  corresponding  tasks,  and  Ofi)  that  all  monitor 
rendezvous  terminate.  Given  an  execution  E  of  P.  it  is  then  possible  to  construct  a 
corresponding  E'  of  P’  by  scheduling  the  runnable  tasks  so  that  corresponding 
tasks  execute  corresponding  code  in  the  order  of  E;  the  monitor  M  is  given  super- 
high  priority.  We  note  that  every  declaration  and  allocate  statement  of  P 
corresponds  to  a  declaration  or  allocate  of  the  same  kind,  so  that  at  any  point  in  E 
and  E’  where  correspondence  has  been  established,  corresponding  tasks  have 
been  allocated  and  activated. 

Claim  2.  In  two  corresponding  computations  of  P  and  P',  the  sequences  of  status  changes  of 
corresponding  tasks,  except  for  monitor  rendezvous,  are  the  same. 

Notes:  This  requires  noting  that  not  only  are  the  direct  status  changes  of  corresponding 
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tasks  ths  same,  but  corresponding  tasks  invoke  the  same  indirect  status  changes 
on  corresponding  tasks  in  executions  that  correspond.  This  latter  results  from 
noting  that  corresponding  entry  calls  are  to  entries  with  the  same  name. 

Claim  3.  If  execution  E  of  P  corresponds  to  execution  E'  of  P'  then  the  only  possible  task  in  E’  that 
does  not  correspond  to  a  task  in  E  is  the  monitor  M. 

Mofes;  This  depends  on  an  analysis  of  the  declarations  in^ed  by  the  preprocessing, 
showing  that  any  task  that  could  be  invoked  in  P‘  other  than  M  has  code 
corresponding  to  code  in  P  in  its  body. 

Claim  4.  For  each  potentiai  deadness  error  of  P.  P*  has  an  equivalent  potential  deadness  error,  and 
conversely. 

Mofes:  Let  deadnesa  error  S  occur  in  sKocution  E  of  P.  Lot  E*  be  a  corresponding 
execution  of  P*  (Ctaim  1).  Using  Claim  2  and  termination  of  Monitor  rendezvous,  all 
tasks  of  E’  that  correspond  to  tasks  in  E  will  reach  the  status  of  their  corresponding 
task  in  S.  At  that  point  in  E’,  the  monitor  M  must  be  blocked  in  accepting  status. 
By  Claim  3,  the  scheduling  state  of  E'  is  equivalent  to  S. 

The  converse  can  be  tugued  similatrly  by  considering  corresponding  executions. 


Note: 

Ctaim  4  states  that  adding  monitor  to  P  does  not  interfere  with  P  (see  Section  2.3). 


5.2  CORRECT  PREDICTIVE  MONITORING 

Consider  a  monitored  program  P'.  Recall  that  any  execution  of  P’  contains  one  task,  the  monitor  M, 
which  does  not  correspond  to  a  task  in  a  corresponding  execution  of  the  unmonitored  program  P.  A 
crucial  property  of  the  preprocessing  (Chapter  4)  'is  that  during  an  execution  of  P',  any  task  t  that 
makes  a  direct  change  of  status  in  attempting  to  rendezvous  with  a  task  other  than  M,  will  call  the 
appropriate  entry  of  M  before  making  that  status  change,  and  when  t  is  returned  to  running  status  as 
a  result  of  completion  of  the  monitor  call,  its  next  status  change  normally  will  be  the  one  signalled. 
We  call  this  property  of  the  preprocessing  pndietivB  monitoring.  As  a  result  of  predictive  monitoring, 
the  monitor’s  representation  of  the  scheduling  states  of  P’  is  always  ahead  of-the  actual  scheduling 
state  in  any  computation. 

Claim  5  If  at  any  point  in  an  execution  of  P*  the  monitor  M  has  an  entry  call  from  task  t  implying  a 
change  of  status  from  running  to  s,  then  after  the  monitor  rendezvous  with  t  terminates,  t 
will  be  in  status  running  and  if  it  continues  normally  its  next  status  change  (if  any)  is  to  a 

Notos;  This  depends  on  a  case  analysis  of  the  clauses  in  the  preprocessing.  Various 
complicationa  must  be  noted,  e.g.  that  any  actual  parameter  expressions  of  entry 
calls  or  select  alternatives  are  "unwound"  and  their  values  assigned  to  temporary 
variables  prior  to  the  monitor  call.  Note  that  the  claim  allows  for  the  case  where  the 
scheduler  does  not  run  t  again  in  that  execution. 


Predictive  monitoring  enables  the  monitor  to  update  its  representation  of  the  scheduling  state  to 


40 


rtfitct  a  future  stata  undar  tha  assumption  that  runnabia  tasks  wiH  aventually  run.  Oaadnass  errors 
that  are  reprasented  in  tha  monitor  therefore  must  aventually  happen  in  tha  execution.  Tha  pradictiva 
property  enables  tha  monitor  to  signal  tasks  to  take  evasive  action  before  a  deadneas  error  actually 
occurs. 


S.3  MONITOR  CORRECTNESS  AND  COMPLETENESS 

Three  crucial  propamas  of  tha  monitor  Implamantation  must  be  proved:  0)  all  monitor  entry  calls 
tsrminata;  (B)  the  monitor*a  repraaantstlon  of  scheduling  staisa  eorreetfy  reprasants  tha  scheduling 
state  impliad  by  any  legal  aaquanea  (La.,  a  aaquanea  that  can  occur  in  a  computation)  of  monitor 
entry  calls  from  a  preprocaasad  program.  (Bl)  tha  monitor  wil  dotact  any  dsadnsss  error  that  is  a 
eonaaquanca  of  Ms  rspreaantatlon  and  that  thaaa  arrore  induda  gloM  bloeking  and  circular 
deadlock,  (Certain  daadnaas  arrore  may  not  be  adaquataiy  rspraaantsd.  and  therefore  not 
daiectabla.) 


Notes: 

Arguments  supporting  these  claims  must  be  based  on  the  implementation  description  given  in  ' 
Chapter  3. 

Note  that  a  proof  of  (ii)  requires  showing  mat  indirect  status  changes  implied  by  a  direct  change  are 
reprasented  correctly  when  an  entry  call »  completed.. 
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6.  EVASIVE  ACTION 


In  this  chapter  we  outline  some  paradigm  techniques  for  programming  evasive  action  in  the 
monitored  program.  These  paradigms  use  Ada  exception  propagation,  and  therefore  differ  from  our 
present  implementation  and  examples. 

Notts: 

The  facflitieo  provided  by  our  monitor  for  evasive  action  depend  on  procedure  parameters  (e.g. 
OEAOLK_FLA6  parameter  of  CALLING  because  of  deficiencies  in  the  Adam  compiler,  aimiiarly,  the 
example  experiment  given  in  Section  7*A^does  notuse  exceptions. 

It  is  asaumod  that  the  monitor  may  propagate  a  number  of  exceptions  signifying  the  imminent 
occurrence  of  dMferant  kinds  of  dead  alatas.  for  axampie: 

6L0BAL.BL0CKIN6.  CIRCULAR.OEAOLOCK. 

OEPENOENTS.BLOCKEO.  LOCAL.BLOCKING  :  exception 

In  most  cases  the  monitor  will  propagate  an  exception  to  the  final  task  whose  status  change  will 
complete  a  dead  state.  We  may  call  this  the  ’’offending"  task,  although  it  may  be  no  more  of  an 
offender  than  other  tasks  who  have  already  reached  blocked  statuses.  In  more  sophisticated 
monitoring  systems,  exceptions  may  be  propagated  to  other  tasks  in  the  monitored  system. 

There  are  three  paradigms  for  using  the  propagation  of  such  exceptions  in  the  source  text  to  enable 
the  monitored  program  to  take  evasive  action. 


6.1  MINOR  EVASION 

The  evasive  action  is  taken  and  then  the  program  proceeds  exactly  as  normal  (i.e.,  as  it  would  have  if 
no  deadness  exception  had  been  propagated  ffom  the  monitor).  This  technique  may  be  used  in 
cases  where  the  imminent  error  may  be  avoided,  e.g.  by  freeing  a  resource  and  delaying,  and  then 
acquiring  the  resource  again. 


begin 

MONITOR. CALLING(MY.IO.  S_ID. 
exception 

when  GLOBAL.BLOCKING  •>  — 

end; 


S.E; 


Block  enclosing  monitor  csll. 
•E ’ ) ;  —  intention  to  ceil  S 

Evssive  setion 

~~  Continue  to  csll  S  ss  pisnned. 


6.2  MAJOR  EVASION 

A  major  evasion  requires  thp  program  to  disrupt  its  normal  course  of  action.  A  standard  example 
would  be  that  the  "offending"  task  reset  its  local  data  and  return  to  some  previous  starting  point. 


Exsmple: 
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loop 

•  •  • 
bogin 

MONITOR. CALLING  (MY  10,  S 
S.E; 
oxeoption 

whon  GL0BAL_BL0CKING  •> 

ond; 


“  Monitor  caJi  and  intandad  task  action 
.10 .  •  E  " ) ;  —  ara  placed  in  a  block; 

—  Normal  action  is  to  call  S. 

—  Evasive  action  whan  ERROR  is 

—  propagated  by  the  monitor  call. 

—  Do  not  call  S  after  evasive  action, 

“  but  continue  here. 


6.3  CATASTROPHE 

In  a  eatastropho  thoro  la  no  hopo  of  *tlio  offanding  taak(a)”  continuing  to  function  uaafully.  If  this 
kind  of  error  is  aignailad  tho  offandor  win  afmpfy  report  di^nostics  and  possibfy  transmit  warnings  to 
other  tasks  in  the  program.  The  rej:orting  can  be  based  on  "questioning”  the  monitor. 


Example: 

task  body  T  is 
«  •  « 
begin 

MONITOR. CALLING  (MY_I0.  S_I0.  "E"); 

S.E; 

exception 

when  GL08AL.8L0CXNG  •> 

Report  conditions  and  then  die  gracefully;  do  not  continue. 
end  T; 
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7.  EXAMPLES 


In  this  chapter  we  give  examples  of  h^e  pre-processing  transformation,  of  the  monitor's  output 
describing  deadness  errors,  and  of  evasive  action. 


7.1  A  DINING  PHILOSOPHERS  PROGRAM 

The  following  example  is  the  version  of  the  dining  philosophers  problem  with  a  potential  blocking 
error  given  by  Hoare  in  his  paper  on  Communicating  Sequential  Processes.  The  example  gives  the 
original  Ada  text  and  the  preprocessed  text  The  output  comments  from  the  monitor  describing  the 
blocking  error  when  it  ooeurrad  are  alao  given. 

Blocking  can  occur  as  follows. 

All  five  philosophers  can  enter  the  room,  sit  down  at  the  table  and  pickup  one  fork;  then  all 
forks  will  be  in  accepting  status  waiting  for  a  PUTDOWN,  while  all  philosophers  will  be  in 
calling  status  having  called  PICKUP  for  their  second  fork,  and  the  table  will  be  waiting  for 
either  of  its  entries  to  be  called. 

Whether  or  not  this  situation  will  happen  depends  on  the  underlying  scheduling.  The  error  may  never 
occur  or  may  occur  almost  immediately,  depending  on  the  runtime  task  supervisor.  This  is  illustrated 
by  the  delay  statements  in  the  Philosopher  task  body.  If  the  delay  before  picking  up  the  second  fork  is 
removed,  the  blocked  state  will  never  occur  when  the  program  is  run  with  the  task  supervisor  package 
at  Stanford;  with  this  delay,  the  tasks  block  before  any  philosopher  eats. 

with  0T7Y_I0: 
use  OTTY.IO; 

procedure  ROOM  is 
pragma  MAIN; 

task  type  FORK  is 
entry  PICKUP: 
entry  PUTDOWN; 
end  FORK; 

task  TABLE  is 

entry  SITDOWN  (I  :  out  INTEGER); 
entry  GETUP  (I  :  In  INTEGER); 
end  TABLE; 

task  type  PHILOSOPHER: 

type  SET_OF_FORKS  is  array  (0  ,.  4)  of  FORK; 

FORKS  ;  SET_0F_F0RKS; 

—  The  scripts:  the  bodies  of  the  actors. 

task  body  FORK  is 
begin 
loop 


—  The  cast  of  actors:  FORKS, 

—  PHiLOSOPHERS.  and  TABLE. 


accept  PICKUP; 
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aeeapt  PUTOOWN; 
•nd  loop; 
and  FORK; 


task  body  TABLE  is 


typo  SEAT.ARRAY  is  array  (0  ..  4)  of  BOOLEAN; 

SEATS  :  SEAT_ARRAY  :•  (othars  >>  TRUE): 

**  Tnia  moans  unoccupied. 


bagin 


salaei 

.  aeeapt  SITOOtfN  (I  ;  out  INTEGER)  do 
for  J  in  0..4  loop 
r  :■  J; 

oxH  whan  SEATS  (J): 
and  loop: 

SEATS  (I)  :•  FALSE; 

and; 

or 

accapt  GETUP  (I  :  in  INTEGER)  do 
SEATS  (I)  :•  TRUE; 

and; 

and  salaet; 
and  loop; 

and  TABLE; 

task  body  PHILOSOPHER  is 
SEAT  :  INTEGER: 
bagin 
loop 

dalay  1 ;  —  Delays  are  for  thought.  H  a  large  enough 

TABLE . SITDOWN  ( SEAT ) ;  —  delay  is  placed  between  picking  up  the 
FORKS  (SEAT)  .  PICKUP:  —  two  torks  then  the  blocked  state  occurs; 
dalay  2;  --  It  not.  the  philosophers  don’t  block. 

FORKS  ((SEAT  ♦  1)  mod  5), PICKUP; 

—  This  illustrates  the  dependence  of 
““  the  error  on  the  runtime  supervision. 

dalay  1; 

FORKS  (SEAT). PUTOOWN; 

FORKS  ((SEAT  ♦  1)  mod  5). PUTOOWN; 

TABLE. GETUP  (SEKT); 
and  loop ; 

and  PHILOSOPHER; 

SOCRATES.  PLATO.  ARISTOTLE.  MARX.  RUSSELL  :  PHILOSOPHER; 

bagin  ~  The  five  forks,  five  philosophers,  and  the 

null ;  —  table  are  all  activated  at  this  point. 

and  ROOM; 


I 
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7.2  THE  PREPROCESSED  AND  MONITORED  DINING  PHILOSOPHERS 


Th«  source  code  of  the  Dining  Phiiosophers  program  after  pre>processing  is  given.  The  reader 
shouid  compare  this  version  with  the  original  text  in  Section  7.1  emd  with  the  descriptions  of  pre¬ 
processing  in  Chapter  4. 

with  MONITOR  DATA.PACKAGE ;  use  MONITOR.OATA.PACKAGE ; 
with  DTTY.IO; 
use  OTTY.IO; 

"  The  cssf  of  actors:  FORKS.  PHILOSOPHERS,  tnd  TABLE. 
procedure  ROOM  Is ,  . 

»  The  DEADLOCK  MONITOR  itself. 


task  MONITOR  la 


•  •  • 
read: 

task  body  MONITOR  is 
end  MONITOR; 


Uses  MONITOR  BASE  PACKAGE 


pragma  MAIN; 

Varisbies  and  new  type  declarations  are  inserted  by  Pass  t,  (Section  4. 1) 
to  introduce  task  ids;  compare  with  declarations  in  Section  7. 1. 

MY_I0  :  constant  TASK_I0  :■  0; 

M0N_DEPEN0  ID  :  IO_PTR; 

MORALIST  ;  ENTRY^PTR; 

M0N_DEA0LK_FLA6  :  BOOLEAN; 

task  type  MONTYPE^FORK  Is 

entry  SET.IO  (N  :  in  INTEGER); 

entry  PICKUP  (CALL.ID  :  in  INTEGER); 

entry  FUTOOWN  (CALL.I0  :  in  INTEGER); 

end  MONTYPE_FORK; 

type  FORK  is 
record 

TSKOBJ  ;  MONTYPE.FORK; 

10  :  INTEGER: 

end  record: 

task  type  MONTYPE.TASLE  is 

entry  SET_ID  (N  ;  in  INTEGER); 

entry  SITOOWN  (CALL.IO  :  in  INTEGER:  I  :  out  INTEGER)  ; 

entry  GETUP  (CALL.IO  :  in  INTEGER;  I  :  in  INTEGER); 

end  MONTYPE.TABLE; 

type  MONREC.TABLE  is 
record 

TSK03J  :  MONTYPE.TABLE; 

10  :  INTEGER: 

end  record; 


TABLE  :  MONREC.TABLE 
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task  typa  MONTYPE.PHILOSOPHER  is 
antry  SET.IO  (N  :  in  INTEGER): 

and; 

typa  PHILOSOPHER  is 
raeord 

TSKOBJ  :  MONTYPE.PHILOSOPHER; 

ID  :  INTEGER:  . 
and  raeord: 

typa  SET.OF.FORKS  la  array  (0  ..  4)  of  FORK; 

FORKS  :  SET.OF.FORKS; 

—  TTia  scripts:  ths  bodies  of  ths  setors. 

taak  body  M0NTYPE.F0RK  la 

NY.IO  :  INTEGER: 

M0H_0EPEM0_I0  :  lO.PTR; 

MON_LIST  :  ENTRY.PTR: 

MON_DEAOLK_FLAG  :  BOOLEAN: 

ALL.OEPENDENTS  :  ID_PTR; 
begin 

aecapt  SET.IO  (N  :  in  INTEGER)  do 

—  Tssk  wsits  until  its  ID  is  initislized 
—  (Section  4. 1) 

MY.IO  :■  N; 
and: 

loop 

MONITOR. ACCEPTING(MY_IO,  -PICKU" .  MON.OEAOLK.FLAG ) ; 
accapt  PICKUP  (CALL.IO  :  in  INTEGER)  do 

MONITOR.START.RENOE2VOUS  (CALL_ID.  MY_ID.  "PICKU"): 
MONITOR. ENO_RENOEZVOUS  (CALL.ID,  MY.ID.  "PICKU"): 

and: 

MONITOR. ACCEPTING  (MY_ID.  "PUTDO".  MON_DEADLK_FLAG) ; 
accapt  PUTDOWN  (CALL.IO  :  in  INTEGER)  do 

MONITOR. START.RENOEZVOUS  (CALL.IO,  MY.IO.  "PUTDO"): 
MONITOR. ENO.RENOEZVOUS  (CALL.IO,  MY.ID,  "PUTDO"): 

and: 
and  loop : 

MONITOR. ENO.TASK  (MY.ID.  MON.DEPEND.ID .  MON.DEAOLK.FLAG) : 
and  MONTYPE.FORK: 

task  body  MONTYPE.TABLE  is 

MY  ID  :  INTEGER: 

MON.DEPEND.ID  :  ID.PTR: 

MON.LIST  :  ENTRY.PTR: 

MON.DEAOLK  FLAG  :  BOOLEAN: 

ALL.OEPENOEMTS  :  ID.PTR: 


typa  SEAT.ARRAY  is  array  (0  ..  4)  of  BOOLEAN: 
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SEATS  ;  SEAT_ARRAY  :•  (Others  ->  TRUE); 
begin 

accept  SET.ID  (N  :  in  INTEGER)  do 
MY_I0  H; 

end; 

loop 

if  not  FALSE  then 

MON_LIST  :■  null; 
if  TRUE  then 

MON.LIST  new  MON_ENT_REC(NAME  ->"S1TD0", 

NEXT  »>  MON.LIST) ; 

end  if; 

If  TRUE  then 

MON.LIST  new  MON.ENT_REC(NAME  ->''GETUP”. 

NEXT  >>  NON.LIST); 

end  if; 

MONITOR. SELECTIMG(MY_ID,  MON.LIST,  FALSE. 

MON_OEPEND_ID.  MON_DEADLK_FLAG) : 

end  if : 
select 

accept  SITOOWN  (CALL.ID  :  in  INTEGER: 

I  :  out  INTEGER)  do 

MONITOR. START_RENDEZV0US(CAL1_ID.  MY_ID.  "SITDO"); 
for  J  in  0..4  loop 
I  :«  J ; 

exit  when  SEATS(J); 
end  loop ; 

SEATS(I)  :«  FALSE; 

MONITOR. END_RENDEZVOUS  (CALL.ID,  MY_ID.  "SITDO"): 

end: 


or 

accept  GETUP  (CALL_IO  :  in  INTEGER; 

I  :  in  INTEGER)  do 

MONITOR. START_RENDEZVOUS  (CALL.IO,  MY_ID.  "GETUP"); 
SEATS(I)  :•  TRUE; 

MONITOR. EMO.RENOeZVOUS  (CALL.ID,  MY_ID.  "SITDO"); 

end; 

end  select ; 
end  loop ; 

MONITOR. END_TASK  (MY.IO.  MON_DEPENO_ID .  MON_DEADLK_FLAG) ; 
end  MONTYPE.TABLE; 

task  body  MONTYPE.PHILOSOPHER  is 
MY_ID  ;  INTEGER; 

M0N_0EPEND_I0  :  ID_PTR; 

MORALIST  ;  ENTRY^PTR; 

MON_DEAOLK_FLAG  :  BOOLEAN; 

ALL.DEPENOENTS  :  ID_PTR; 

SEAT  :  INTEGER; 
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b«9in 

aeevpt  SET.ID  (N  :  in  INTEGER)  do 
MY_ID  N: 

•nd; 

loop 

dolay  1; 

MONITOR. CALLING  (MY_ID.  TABLE. ID,  "SITDO",  MON_DEAOLK_FLAG) ; 

TABLE. TSKOBJ.SITOOWN  (MY.IO.SEAT) ; 

MONITOR. CALLING  (MY_IO.  FORKS(SEAT) .10 .  "PICKU",  MON_DEAOLK_FLAG) ; 
FORKS  ( SEAT ).TSK0BJ. PICKUP  (MY.IO): 
dolay  2; 

MONITOR. CALLING  (MY.IO,  FORKS  ((SEAT  +  1)  6). ID.  "PICKU", 

MON.OEAOLK.FLAG) : 

FORKS  ((SEAT  *  1)  nod  6 ).TSK0BJ. PICKUP  (MY.IO): 
dalay  1: 

MONITOR. CALLING(MY  ID.  FORKS  (SEAT) .  ID.  "PUTDO"  .MON_DEADLK_FLA.G) ; 
FORKS  (SEAT).TSKOBJ.PUTDOWN  (MY_ID): 

MONITOR. CALLING  (MY.IO,  FORKS  ((SEAT+l)  mod  5). ID.  "PUTOO". 

MON.DEADLK.FLAG); 

•  FORKS  ((SEAT+1)  mod  5) .TSKOBJ.PUTDOWN  (MY_ID); 

MONITOR. CALLING  (MY_ID . ‘ TABLE. ID ,  "GETUP" .  MON_DEADLK_FLAG ) ; 

TABLE. TSKOBJ.GETUP  (MY.ID.  SEAT);, 

and  loop; 

MONITOR. ENO.TASK  (MY.ID,  MON_DEPENO_ID .  MON_DEADLK_FLAG) : 
and  MONTYPE.PHILOSOPHER; 

SOCRATES  :  PHILOSOPHER; 

PLATO  ;  PHILOSOPHER; 

ARISTOTLE  :  PHILOSOPHER; 

MARX  :  PHILOSOPHER; 

RUSSELL  :  PHILOSOPHER; 
bagin 

—  Monitor  calls  inserted  by  Pass  2  (Section  4.2)  to  initialize  all  task  ids  in  task  records, 

—  and  track  task  dependencies  (Section  4.3) 

MONITOR. NEWTASK  ("TABLE".  TABLE. ID); 

MONITOR. AD0_0EPENDENT  (MY.IO,  TABLE. ID,  MON_OEPEND_ID.  ALL_OEPENDENTS) ; 

(or  MON  II  in  0  ..  4  loop 

MONITOR. NEWTASK  ("FORKS".  FORKS ( MON.Il ). ID) ; 

MONITOR. ADO.OEPENOENT  (MY.ID.  MON_DEPEND_ID .  FORKS  (MON^Il ) . ID) ; 
and  loop ; 

MONITOR. NEWTASK  ("SOCRA",  SOCRATES. ID) ; 

MONITOR. ADD  DEPENDENT  (MY.ID.  MON_DEPENO.ID.  SOCRATES. ID) ; 

MONITOR. NEWTASK  ("PLATO",  PLATO. ID); 

MONITOR. ADD  DEPENDENT  (MY_ID.  MON_D£PEND.ID.  PLATO. ID); 

MONITOR. NEWTASK  ("ARIST",  ARISTOTLE. ID) ; 

MONITOR. ADO  DEPENDENT  (MY.ID.  MON_OEPEND.ID,  ARISTOTLE . ID) ; 
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MONITOR. NEWTASK  ("MARX  MARX. ID): 

MONITOR. ADD.DEPEMOENT  (MY_ID.  MON_DEPENO_IO.  MARX. ID); 
MONITOR. NEWTASK  ("RUSSE".  RUSSELL. ID); 

MONITOR. ADD_DEPENDENT  (MY.ID.  MON_DEPEND_ID .  RUSSELL. ID); 

—  SET  ID  calls  to  inform  each  task  of  its  ID  inserted  by  Pass  2  (Section  4.2). 
TABLE. TSKOBJ.SET_ID  (TABLE. 10); 
for  MON.Il  in  0  ..  4  loop 

FORKS  (MON.Il).TSKOBJ.SET.ID  (FORKS  (MON.Il) . ID) ; 
ond  loop ; 

SOCRATES . TSKOB J . SET_ID  ( SOCRATES . ID) ; 

PUTO.TSKOBJ.SET_ID  (PLATO. ID); 

ARISTOTLE . TSKOBJ . SET.IO  ( ARIStOTLE . ID) ; 

MARX.TSKOBJ.SET.ID  (MARX. ID): 

RUSSELL. TSKOBJ. SET.IO  ( RUSSELL. ID ) ; 
null: 

MONITOR. END_TASK  (MY_ID.  M0N_0EPEND_ID .  M0N_0EADLK_FLAG) ; 
end  ROOM; 


7.3  DIAGNOSTIC  DESCRIPTION  OF  THE  DINING  PHILOSOPHER’S  DEAD  STATE 


Below  is  the  description  of  a  global  blocking  state  given  by  the  monitor. 

Key:  In  descriptions  of  Accepting  status,  each  entry  name  is  followed  by  it’s  queue  size  (an  integer) 
and  a "  * "  if  the  task  is  in  a  status  accepting  that  entry. 

-MON-*  GLOBAL  DEADNESS  HAS  BEEN  DETECTED 
••MON**  TASK  INFORMATION 

0  MAIN  is  block.waiting  on  11  tasks. 

Its  entries  are: 

<NONE> 

Its  father  is;  -1 

—  This  description  indicates  that  the  table  task  was  in  accepting  status. 

—  accepting  either  entry,  and  neither  entry  had  been  called. 

1  TABLE  is  accepting 

Its  entries  are: 

SITDO  (0*)  6ETUP  (0*) 

Its  father  is:  0 

—  Fork  indicated  as  task  2  is  in  status  accepting  PUTDOWN  which  no  callers. 

—  while  some  task  has  called  PICKUP. 

2  FORKS  is  accepting 

Its  entries  are: 

PUTOO  (0*)  PICKU  (1) 

Its  father  is:  0 

3  FORKS  is  accepting 

Its  entries  are: 


so 


PUTOO  (0*) 
Its  father  Is:  0 

4  FORKS  Is  accepting 

Its  entries  are: 

PUTOO  (0«) 
Its  father  Is:  0 

5  FORKS  Is  accepting 

Its  entrler  are: 
PUTOO  (0*) 
Its  father  Is:  0 

6  FORKS  Is  accepting 

Its  entries  are: 
PUTOO  (0«) 
Its  father  Is:  0 


PICKU  (1) 


PICKU  (1) 


PICKU  (1) 


PICKU  (1) 


SOCRATES  is  task  7;  It  has  called  task  3  (a  fork)  entry  PICKUP; 
we  can  see  above  that  task  3  is  accepting  PUTDOWN. 


7  SOCRA  Is  calling  task  number  3  at  entry  PICKU 
Its  entries  are: 

<NONC> 

Its  father  Is:  0 


8  PLATO  1s  calling  task  number  4  at  entry  PICKU 

Its  entries  are: 

<N0NC> 

Its  father  Is:  0 

9  ARIST  Is  calling  task  number  5  at  entry  PICKU 

Its  entries  are: 

<NONE> 

Its  father  Is:  0 

10  MARX  Is  calling  task  number  6  at  entry  PICKU 

Its  entries  are: 

<NOttE> 

Its  father  Is:  0 

11  RUSSE  Is  calling  task  number  2  at  entry  PICKU 

Its  entries  are: 

<NONE> 

Its  father  Is:  0 

**MON**  end  of  dead  state  description. 


7.4  THE  EVASIVE  ACTION  PHILOSOPHER  TASK 


The  following  is  an  example  of  a  philosopher  task  with  additional  evasive  action  capability.  If  the  task 
receives  a  warning  from  the  monitor  upon  informing  it  that  the  next  action  is  to  pickup  its  right  hand 
fork,  the  evasive  action  will  be  to  putdown  the  lefthand  fork.  It  will  then  attempt  to  eat  again  as  before. 
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This  can  be  programmed  using  paradigm  6.1,  Section  6.  It  ia  asMmed  that  this  source  text  will  be 
preprocessed  and  monitor  calls  placed  as  usual,  including  the  evasive  action  text 

task  body  PHILOSOPHER  is 
SEAT  :  INTEGER: 
begin 
loop 

delay  1: 

TABLE. SIT00UN( SEAT): 

FORKS (SEAT). PICKUP: 

delay  1: 

begin 

JI0IIIT0R.CALLING(MY_10,F0RKS({SEAT  +  1)  mod  6). ID  "PICKUP"); 
— .  This  GSlI  might  pnpsgsts  GLOBALJLOCKING. 

exception 

when  6L0BAL_BL0CKIIIG  -> 

FORKS ( SEAT ). PUTOOWN ; 

—  fvastVe  action:  put  down  left  hand  fork. 
FORKS{ SEAT). PICKUP; 

—  Try  to  pick  up  both  forks  again. 

end: 

FORKS((SEAT  +  1)  mod  5). PICKUP; 

—  May  get  asms  error  again  here. 

delay  1 : 

FORKS (SEAT). PUTOOWN: 

FORKS  ((SEAT  +1)  mod  5). PUTOOWN; 

TABLE, 6ETUP(SEAT): 
end  loop ; 
exception 

when  GLOBAL. BLOCKING  >> 

—  The  evasive  action  did  not  solve  the  problem,  so  degrade  gracefully. 
end  PHILOSOPHER: 


Since  the  Adam  compiler  does  not  implement  exception  propagation  during  task  rendezvous  (e.g. 
rendezvous  with  the  monitor  task),  evasive  action  in  our  experiments  uses  the  value  of  a  parameter. 
NON.OEAO.FLAG.  The  evasive  action  is  Inserted  after  the  program  has  been  preprocessed  since  we 
do  not  want  the  evasive  action  monitor  calls  to  be  monitored. 

task  body  MONTYPE.PHILOSOPHER  is 
MY_I0  :  INTEGER; 

MON_OEPENO_IO  :  lO.PTR; 

MON_LIST  :  ENTRY.PTR; 

M0N_0EA0LK_FLA6  :  BOOLEAN; 

OUTER  DEPENDENTS  :  ID_PTR  renames  MON_DEPEND_ID; 

SEAT  "  ;  INTEGER; 

begin 

accept  SET.ID  (N  :  in  INTEGER)  do 
MY.ID  :•  N; 

end; 

loop 

delay  1; 

MONITOR. CALLING(MY.ID,  TABLE. ID,  "SITDO",  MON.DEADLK.FLAG) : 


TABLE . TSKOBJ . SITOOWN(MY_IO . SEAT ) ; 


MONITOR . CALLING(MY_IO .  FORKS( SEAT) . ID . -PICKU- ,M0N_DEA0LK_FLA6) ; 
FORKS  (SEAT). TSKOBJ. PICKUP  (MY_ID); 
d«iay  1; 

MONITOR. CALLING(MY_IO.  FORKS((SEAT  *  1)  mod  5). ID.  "PICKU". 

MON_DEAOLK_FLAG) ; 

If  MON.DEAOLK.FLAG  than 

MONITOR. TRACE  (ALL.TASKS,  TRUE): 

MONITOR . UNBLOCK  (MY.ID) ; 

MONITOR. CALLING  (MY.ID.  FORKS (SEAT). ID, 

•PUTDO* , M0N.DEA0LK_FLA6 ) ; 
FORKS  (SEAT). TSKOBJ. PUTDOWN  (MY^IO); 

MONITOR. CALLING  (MY.ID.  FORKS ( SEAT ). ID. 

•PICKU".  MON.DEADLK.FLAG); 
FORKS  (SEAT). TSKOBJ. PICKUP  (MY.ID); 


and  if: 

MONITOR. CALLING(MY.ID.  FORKS((SEAT  •*-  1)  mod  5). ID.  "PICKU". 

MON.DEADLK.FLAG); 


FORKS ((SEAT  ♦  1)  mod  6) .TSKOBJ . PICKUP( MY.ID) : 
dalay  1: 

MONITOR. CALLING( MY.ID.  FORKS(SEAT) . ID . "PUTOO" .  MON.DEADLK.FLAG) : 
FORKS  (SEAT). TSKOBJ. PUTDOWN  (MY.ID); 

MONITOR. CALLIMG( MY.ID.  FORKS((SEAT  ♦  1)  mod  5). ID.  "PUTOO". 

MON.DEADLK.FLAG); 

FORKS  ((SEAT^l)  mod  5). TSKOBJ. PUTDOWN  (MY.ID); 

MONITOR. CALLING  (MY  ID.  TABLE. ID.  "GETUP".  MON.DEADLK.FLAG): 
TABLE. TSKOBJ.GETUP  ( MY.ID. SEAT ) ; 

and  loop: 

MONITOR.ENO.TASK  (MY.ID.  MON.DEPENO.IO .  MOM.DEAOLK.FLAG) ; 
and  MONTYPE.PHILOSOPHER; 


7.5  ACTION  OF  DINING  PHILOSOPHERS  WITH  EVASIVE  ACTION 

Below  is  a  trace  of  activity  by  the  evasive  version  of  the  dining  philosophers.  First  the  monitor 
description  of  an  imminent  dead  state  is  given.  A  philosopher  task  is  warned,  and  a  trace  of  its 
evasive  action  and  subsequent  "normal”  activity  then  foilows. 

Key:  See  example  7.3. 

••MON**  GLOBAL  DEADLOCK  HAS  BEEN  DETECTED 
••MON**  TASK  INFORMATION 
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0  MAIN  Is  b1ocl(.wa1t1ng  on  11  tasks. 

Its  tntrlas  art.: 

<NONE> 

Its  fathar  Is:  -I 

1  TABLE  Is  accopting 

Its  tntrlas  art: 

SITOO  (0*)  GETUP  <0») 

Its  fathar  Is:  0 

2  FORKS  Is  accapting 

Its  tntrlas  art: 

PUTOO  (0»)  PICKU  (t) 

Its  fathar  Is:  0 

3  FORKS  Is  accapting 

Its  tntrlas  art: 

PUTOO  (0*)  PICKU  (1) 

Its  fathar  Is:  0 

4  FORKS  is  accepting 

Its  entries  are: 

PUTOO  (0*}  PICKU  (1) 

Its  father  is:  0 

5  FORKS  is  accepting 

Its  entries  are: 

PUTOO  (0*)  PICKU  (1) 

Its  father  is:  0 

6  FORKS  is  accapting 

Its  entries  art: 

PUTOO  (0-)  PICKU  (1) 

Its  fathar  is:  0 

7  SOCRA  is  calling  task  oumbar  3  at  entry  PICKU 

Its  entries  are: 

<NONE> 

Its  fathar  is:  0 

8  PLATO  is  calling  task  number  4  at  entry  PICKU 

Its  entries  are: 

<NONE> 

Its  fathar  is:  0 

9  ARIST  is  calling  task  number  S  at  entry  PICKU 

Its  entries  are: 

<NONE> 

Its  fathar  is:  0 

10  MARX  is  calling  task  number  8  at  entry  PICKU 

Its  antrlas  are: 

<NONE> 

Its  fathar  is:  0 


— *  RUSSELL  will  b0  th9  phffoaophtr  task  ractMng  the  monitor  warning. 

11  RUSSE  Is  calling  task  nunbar  2  at  entry  PICKU 
Its  entries  are: 

<NONE> 

Its  father  Is:  0 

**MON**  end  of  dead  state  description. 

•*TRC**  call  of  Mnitor  entry  CALLING. 

The  consiMMr  is  11  [RUSSEJ.  The  server  Is  6  [FORKS].  The  entry  Is  [PUTOO] 

—  Th/s  /nd/es/es  that  RUSSELL  la  takhtg  evasrve  action  and  la  putting  down  tha  letthand  fork 

—  kietaad  of  attempting  to  phk  up  tharighthaad  fork.  Nota  that  tha  monitor  eall 

—  to  UNBLOCK  Indleating  airaahta  acOon,  la  not  traced,  but  muat  alraady  have  bean  eallad 

—  ao  that  tha  monitor’a  "pietura"  la  oorraet 

••TRC**  can  of  monitor  entry  START_REMOEZVOUS. 

The  consumer  is  11  [RUSSE].  The  server  is  6  [FORKS].  The  entry  is  [PUTDO] 

••TRC*«  call  of  monitor  entry  END.REMDEZVOUS. 

The  consumer  is  11  [RUSSE].  The  server  Is  6  [FORKS]. 

RUSSELL  has  now  put  down  hia  lah  fork. 

••TRC**  can  of  monitor  entry  CALLING. 

The  consumer  Is  11  [RUSSE].  The  server  Is  6  [FORKS].  The  entry  is  [PICKU] 

■*-  RUSSELL  now  attempts  to  pickup  the  lefthand  fork  again! 

■—  However  ha  will  be  behind  MARX  on  tha  entry  queue. 

••TRC**  call  of  monitor  entry  ACCEPTING. 

The  server  Is  6  [FORKS].  The  entry  Is  [PICKU]. 

A  FORK,  taak  0,  ia  tha  only  unblocked  teak. 

••TRC**  can  of  monitor  entry  START.RENDEZVOUS. 

The  consumer  Is  10  [MARX  ].  The  server  Is  6  [FORKS].  The  entry  Is  [PICKU] 

—  Now  MARX  can  pickup  his  righthand  fork,  which  was  RUSSELL  'a  lefthand  fork. 

••TRC*«  can  of  monitor  entry  ENDURE NOE ZVOUS. 

Tha  consumer  Is  10  [MARX  ].  The  server  Is  8  [FORKS]. 

••TRC**  can  of  monitor  entry  ACCEPTING. 

The  server  Is  6  [FORKS].  The  entry  Is  [PUTOO]. 

••TRC**  can  of  monitor  entry  CALLING. 

The  consumer  Is  10  [MARX  ].  The  server  Is  5  [FORKS].  The  entry  Is  [PUTOO] 

Now  MARX  ia  finished  eating  and  prepares  to  put  down  hia  forks. 

••TRC**  call  of  monitor  entry  START.RENDEZVOUS. 

Tha  consumer  Is  10  [MARX  ].  The  server  Is  5  [FORKS].  The  entry  Is  [PUTDO] 
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••TRC**  call  of  monitor  antry  END.RENOEZVOUS. 

Tha  consumar  Is  10  [MARX  ].  Tha  sarvar  Is  5  [FORKS]. 

••TRC**  call  of  monitor  antry  CALLING. 

Tha  consumar  Is  10  [MARX  ].  Tha  sarvar  Is  6  [FORKS].  Tha  antry  1s  [PUTDO] 

••TRC**  call  of  monitor  antry  ACCEPTING. 

Tha  sarvar  Is  6  [FORKS].  Tha  antry  Is  [PICKU]. 

•■TRC**  call  of  monitor  antry  START.RENDEZVOUS. 

Tha  consuawr  Is  10  [MARX  ].  Tha  sarvar  Is  6  [FORKS].  Tha  antry  Is  [PUTDO] 

**TRC**  call  of  sMnItor  antry  ENO.RENOEZVOUS. 

Tha  consumar  Is  10  [MARX  J.  Tha  sarvar  Is  6  [FORKS]. 

•*TRC**  call  of  monitor  antry  CALLING. 

Tha  consumar  Is  10  [MARX  ].  Tha  sarvar  Is  1  [TABLE].  Tha  antry  Is  [GETUP] 

••TRC**  call  of  monitor  antry  ACCEPTING. 

The  server  is  6  [FORKS].  The  entry  is  [PICKU]. 

••TRC**  call  of  monitor  antry  START.RENOEZVOUS. 

Tha  consumar  Is  9  [ARIST].  Tha  sarvar  Is  5  [FORKS].  Tha  antry  Is  [PICKU]. 

—  ARISTOTLE  gets  liis  righthand  fork  and  starts  eating. 

••TRC**  call  of  monitor  entry  START^REMDEZVOUS. 

The  consumer  is  10  [MARX  ].  Tha  sarvar  is  1  [TABLE].  The  entry  is  [GETUP] 

—  Now  MARX  has  left  the  table. 


The  trace  output  continues  on  indefinitely. 
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